BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / 172bdoc.zip / RBBSDOC2.ASC < prev

Wrap

Text File | 1989-05-27 | 376KB | 6,993 lines

RBBS-PC CPC17-2A Page 143 12. THE HAYES MODEM SWITCH SETTING AND CONSIDERATIONS ----------------------------------------------------- 12.1 Hayes Smartmodem 1200 Switch Considerations ------------------------------------------------ RBBS-PC is tested with a HAYES Smartmodem 1200 (i.e. external). The switch settings on the modem must be as follows: switch -- 12345678 setting - UUDDDUUD Recognizing that there are many "Hayes-compatible" (and not so compatible) modems in use, this section is intended to assist those adventurous souls who use such modems and need some guidance on what the otherwise mystical Hayes switch settings mean. The following table may be of some help: Setting Function to RBBS-PC Hayes | Factory | RBBS-PC | Switch |---------|---------| (NOTE "Up" means enabled or "on") 1 Down Up Allows RBBS-PC to control the modem using the RS-232 DTR lead (pin 20). 2 Up Up Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be English words or single digits. RBBS-PC sets this with the Hayes "V" command. 3 Down Down Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be sent to RBBS-PC. RBBS-PC sets this with the Hayes "Q" command. 4 Up Down The modem does not echo characters unless half-duplex is selected and the modem is on- line. 5 Down Down Modem is NOT to answer incoming calls. RBBS- PC monitors the ring indicator (pin 22) to determine if the phone is ringing. If it is, RBBS-PC will issue the necessary commands to the modem. 6 Down Up RBBS-PC checks for the carrier signal using the RS-232 Carrier Detect lead (pin 8). If carrier is lost, RBBS-PC hangs up the phone and re-cycles to await the next call. 7 Up Up Not really required by RBBS-PC. However in the "down" position, the telephone extension light will illuminate on a multi-line installation when the modem answers a call. 8 Down Down Enables the Smartmodem 1200 to recognize the Hayes commands issued by RBBS-PC. The most common problem, "RBBS-PC continually recycles," occurs when switch six is left in the factory position. These switch settings do not have to be changed for most other RBBS-PC CPC17-2A Page 144 communications software packages. (You can leave the switches set as shown above if you use PC-TALK for your smart terminal communications. However, you will be advised to give the modem an "ATZ" command before using PC-TALK in order to reset the registers correctly.) RBBS-PC should be used only with versions 123 and above of the Hayes Smartmodem 1200 and with version 247 and above of the Hayes Smartmodem 2400. Earlier versions do not answer the telephone properly. The ATI command will cause the Smartmodem to tell you its version. Hayes is now shipping an external modem called the Hayes 1200FE that has 10 switch settings. To run RBBS-PC switches 9 and 10 of the 1200FE must be left up (the factory setting). Hayes is also now shipping an internal modem called the Hayes 1200BFE that has 6 switch settings. To run RBBS-PC switches 4, 5, and 6 must be left up (the factory setting). If you can't figure out what the switching settings on these new modems should be based on the switch settings given for the "original" Hayes 1200, CALL HAYES TECHNICAL SUPPORT! Since I don't have the newer modems, I won't be of much help if you call me. RBBS-PC CPC17-2A Page 145 12.2 Hayes Command's Considerations ----------------------------------- The Hayes commands used to control the modem are all external to RBBS-PC beginning with version CPC13-1A. These command strings are in the RBBS- PC.DEF file which may be modified using CONFIG parameter 225. The RBBS-PC.DEF file contains five Hayes command strings -- one on the second line of the .DEF file and four on the last line of the .DEF file. Using RBBS-PC's CONFIG utility's defaults, the command strings are as follows: 12.2.1 Command to Reset the Modem --------------------------------- The modem reset command is the first option in CONFIG parameter 225 and it's default value is the Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. Z Causes a software reset and applies all default values. This command is ALWAYS issued and is the first command issued to the modem every time RBBS-PC gets ready for calls. 12.2.2 Command to Initialize the Modem -------------------------------------- The modem initialization command is ALWAYS issued and is the second command issued to the modem every time RBBS-PC gets ready for calls. The modem initialization command is the second option in CONFIG parameter 225 and it's default value is one of the following Hayes command strings. If CONFIG has been used to set RBBS-PC to answer on a ring greater than zero, the command string is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Do not return result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds (you may want to set this to 15) E0 Do not echo characters back to the PC when receiving Hayes commands. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. S0=x "x" is set as follows: S0=254 to answer on a specific number of rings > 0 S0=255 to enable "ring-back" RBBS-PC CPC17-2A Page 146 If CONFIG sets RBBS-PC to answer on zero rings, the command string is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Send result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds. Some of the Hayes ROM's have a bug in them that causes the modem to only answer at 1200 baud if anything other than the factory default is used for S10. If you have such a problem, simply set S10 equal to 7. E0 Do not echo characters back to the PC when receiving Hayes commands. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. S0=1 Answer the phone on the first ring. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. 12.2.3 Command to Count The Number of Rings ------------------------------------------- The modem command that counts the number of rings is the third option in CONFIG parameter 225 and it's default value is the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. S1? Requests the modem to return the number of times that the phone has rung. This command string is only issued when CONFIG has been used to tell RBBS- PC to answer on a specific number of rings other than 0. Some modems have trouble with the S1? command because they do not recognize the ? part of the command. Again, verify what your modem is capable of handling. 12.2.4 Command to Answer the Phone ---------------------------------- The modem command to answer the phone is the fourth option in CONFIG parameter 225 and it's default value is one of the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. Q0 Tells the modem to send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. V1 "Extended" result codes are to be transmitted as words. A Tells the modem to answer the phone immediately. This is only issued if the number of rings to answer on is greater than 0. RBBS-PC CPC17-2A Page 147 RBBS-PC utilizes the extended verbal results code (CONNECT, CONNECT 300, CONNECT 1200, and CONNECT 2400) to determine the callers baud rate. Some Hayes 300 modems don't function with RBBS-PC because they do not recognize the "X1" command. If you have a modem like this, simply remove the X1 command from the command strings in the .DEF file. 12.2.5 Command to Take the Phone Off the Hook --------------------------------------------- The modem command to take the phone off the hook is the fifth option in CONFIG parameter 225 and it's default value is the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. Q1 Do not return result codes to the PC. E1 Echo characters back to the PC when handling Hayes commands. H1 Take the modem off the hook (i.e. busy out the line). M0 Turn the monitor speaker on the modem off permanently. This command is ALWAYS issued whenever the SYSOP is doing local maintenance (i.e. hits ESC) or a user hangs up. 12.2.6 Firmware Initialization ------------------------------ The commands to initialize the modem firmware are not contained in the .DEF file, but rather are dynamically set (or reset) each time that CONFIG is invoked. There are essentially three commands: 1. A command to clear the modem's firmware. 2. A command to initialize the modem's firmware. 3. The command to write the initialized firmware to the modem's non-volatile memory is "&W". The modem command to clear the modem's firmware is the sixth option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. &F Load the modem active configuration area with the factory profile contained in the Hayes ROM. RBBS-PC CPC17-2A Page 148 The modem command to initialize the modem's firmware is the seventh option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. &C1 Data carrier detect tracks the state of the data carrier from the remote modem. &D3 Modem is to assume the initialization state if it detects ON- to-OFF transition of DTR. The newer versions of the Hayes 2400 baud modem (ROM 249 or greater) and some clones do not allow RBBS-PC to recycle properly when the &D switch is set to 3. If you are having a problem, set the it to &D2. B1 Set the modem to Bell 212A mode when the 1200 BPS data transfer rate is selected. E0 Do not echo characters of the modem commands issued by RBBS-PC back to the PC running RBBS-PC. V1 Select long-form result codes. M0 Disable the modem's speaker when carrier is detected. S0=0 Disable "auto-answer" mode. &T5 Disallow a request from the remote modem for a remote digital loopback test. The modem command to write the initialized firmware to the modem's non- volatile memory is the sixth option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning &W Write the firmware settings to non-volatile memory These three commands are ALWAYS issued in CONFIG when parameter 231 is selected. These commands can be temporarily altered by changing them via parameter 225 of CONFIG prior to invoking parameter 231. RBBS-PC CPC17-2A Page 149 12.2.7 Smartmodem 9600 Firmware Initialization ---------------------------------------------- The Hayes V-series Smartmodem 9600's active configuration should be: B1 -- Factory setting E1 -- Factory setting L1 -- Low speaker volume (unless you like noise). M1 -- Factory setting N1 -- Factory setting Q0 -- Factory setting T -- touch tone (could be "P" for pulse dial). V1 -- Factory setting W1 -- Modem reports error-control call (i.e. LAP-B/HDX). X1 -- Send result basic result codes plus CONNECT 1200, 2400, etc. Y0 -- Factory setting &C1 -- Factory setting &D2 -- Disable auto-answer when carrier drops. &G0 -- Factory setting &J0 -- Factory setting &K3 -- Factory setting &L0 -- Factory setting &P0 -- Factory setting &Q5 -- Factory setting &R0 -- Factory setting &S1 -- Data Set Ready operates according to RS-232C standards. &T5 -- Deny requests for remote loop back tests from calling modem. &X0 -- Factory setting &Y0 -- Factory setting S00:254 -- Let phone ring 254 times before automatically answering it. S01:000 -- Factory setting S02:043 -- Factory setting S03:013 -- Factory setting S04:010 -- Factory setting S05:008 -- Factory setting S06:002 -- Factory setting S07:054 -- Assume no carrier is detected within 54 seconds of answering. S08:002 -- Factory setting S09:006 -- Factory setting S10:030 -- Let carrier drop for up to 30 seconds before disconnecting. S11:095 -- Factory setting S12:050 -- Factory setting S18:000 -- Factory setting S25:005 -- Factory setting S26:001 -- Factory setting S36:001 -- Factory setting S37:000 -- Factory setting S38:020 -- Factory setting The Hayes V-series Smartmodem 9600's have non-volatile memory that contains three different possible configurations -- 1. the active configuration, 2. the profile 0 configuration, and 3. the profile 1 configuration. To utilize the Hayes V-series 9600 modems with RBBS-PC, it is necessary that the SYSOP 1. set the active configuration as shown on the previous pages, and 2. write this active configuration to profile 0 with the &W0 command. RBBS-PC CPC17-2A Page 150 This can be done by temporarily re-CONFIGuring the default modem firmware initialization commands via parameter 225 (items 6, 7, and 8) before initializing the Hayes Smartmodem 9600's firmware via parameter 231. RBBS-PC is able to interface with the Hayes V-series Smartmodem 9600 at 300, 1200, 2400, 4800, and 9600 baud. When operating at the two highest baud rates, the Hayes V-series Smartmodem 9600 is limited to connecting with only other Hayes V-series Smartmodem 9600's. RBBS-PC recognizes whenever the Hayes version of error-correction protocol, "LAP-B", is enabled between the caller and RBBS-PC. RBBS-PC has been tested with the above active configuration and no problems have been encountered using the "internal" protocols supplied with RBBS-PC. Questions regarding the Hayes V-series 9600 modems and any of the "external" protocols which a SYSOP may choose to make available should be addressed to the authors of such protocols. RBBS-PC CPC17-2A Page 151 13. RBBS-PC's FILE MANAGEMENT SUBSYSTEM ---------------------------------------- The File Subsystem is the method by which RBBS-PC maintains the list of files that are available for downloading which a caller can list. Some features of the File System are the ability to list files after a certain date, to list files having a string in their header, and to list files by category. RBBS-PC refers to a file that contains a list of files available for downloading as a "directory" (i.e. a .DIR file). There are two possible extremes when working with the File System. One is to have multiple separate "directory" files. The other extreme is to have a single master "directory" file (i.e. a single FMS file) that contains the names, sizes, dates, and description of all the files available for downloading. You may use both ideas at once if you wish. It is perfectly allowable to use the master FMS directory as well as the smaller ones. CONFIG parameter 215 controls whether RBBS-PC looks beyond the FMS directories. If you have any separate directories, set 215 to NO. If you have only a single FMS directory, set parameter 215 to YES. If directory searches are not limited to the FMS directories and RBBS-PC does not find the category in the FMS listing, it will look for the old-style DIR files. RBBS-PC CPC17-2A Page 152 13.1 Multiple Directory Format ------------------------------ The multiple directories, also referred to as the old-style directories, are simply text files. They consist of a filename ending in a certain extension, specified in CONFIG, common to all the directories. The default extension is .DIR, but it can be changed via parameter 209. There is a directory which lists the directory names and their descriptions whose name is specified via parameter 211 of CONFIG. Each directory is simply a text file. It may have anything in it, including ANSI codes. The only restriction is that in order for the N)ew command to work properly, the date must be somewhere in the first 31 characters. A file is classified in a directory simply by being put into the file. The SYSOP can allow the caller to classify uploads (by setting the minimum security for classifying to a low enough value). All uploads must go into a single directory, called the upload directory, specified in parameter 202, and it will be in the drive\path specified in parameter 203. All other directories must be in the drive\path specified in parameter 220. This includes the FMS directory (MASTER.DIR) and the list of DIR files, (DIR.DIR). There are, therefore, four logical areas into which the file subsystem is divided. Each one may reside in a separate DOS directory, or all of them may be lumped together into one main directory. Logical Area CONFIG 1. The files for DOWNLOAD parameter 204, parameter 205, and parameter 207 2. The files that have been uploaded parameter 201 and parameter 206 3. The upload directory file listing. parameter 202 and parameter 203 4. The download directory files. parameter 220 The files in the download directory are the only files that may be downloaded. The SYSOP may elect to have the upload directory also a download subdirectory. This can be done by specifying it in the download "PATH". One interesting feature of the File Subsystem is that you can build a "chain" of drives and subdirectories to search for a given file. The SYSOP, via parameter 204, can list the order of the drives to be searched when RBBS-PC is looking for the file to be downloaded. The parameter is specified with simply the letters, together. For example: BAC would search Drive B, then Drive A, then Drive C. Use this parameter if you want to search more than one drive. If the files are not in the default directory then you need to use the CONFIG parameter 205 and parameter 207. Parameter 205 specifies that you want to sue DOS sub-directories and parameter 207 allows you to list them. Use drive:\path format. Multiple directory .DIR files and the single FMS directory entry formats are the same (see section 13.4) except that the old style separate directories need not be fixed length and don't include the category code. Any directory can be in the Single FMS format. This allows special purpose directories to be put into FMS format so they can take advantage of such features as resumable listings normally associated just with the Single FMS environment. An unlimited number of lines of text can be added to any description (see CONFIG parameter 40, parameter 148, and parameter 153). RBBS-PC CPC17-2A Page 153 The file directories have absolutely no bearing on what is in the subdirectory. A file can be listed but not exist, and a file, such as one uploaded with the / for SYSOP option, may exist but not be entered. The file directories are simply methods to get the caller a listing of the files available. RBBS-PC CPC17-2A Page 154 13.2 The Single and Chained FMS Directory Format ------------------------------------------------ FMS logically just lumps all the old style separate directories into one directory file, called the MASTER or FMS directory, and assigning each file a CATEGORY CODE, which may correspond to the directory it was in the original directories. A utility program called CNVDIR.EXE will do exactly this: combine the separate directories and add the category code at the end. If you do not already have separate directories, simply set it up with a text editor using the columns indicated. Beginning with CPC17-2A FMS directories can be "chained". This means that physically separate files can be logically combined to form a single FMS directory. This is accomplished by putting the following in the header record (a header record in an FMS directory is the first record and must begin with "\FMS "): CH(<chain to>) where <chain to> is the name of the file to chain to. As an example \FMS CH(C:\DIRS\CHTO.DIR) would chain to the file "C:\DIRS\CHTO.DIR". Names of files not in the default directory must have a drive and/or path specified. The directory chained to can in turn have a chain, and there is no limit to the number that can be chained together. The directory chained to is an independent FMS directory and can be anywhere and have any extension. A given directory can have at most one directory to chain to. Chained directories can be used to keep the upload directory small for easier editing, or to better fit the latest directories on a fast RAM disk while keeping older directories on a slower hard disk (e.g. a SYSOP divides the directories into UPLOADS.DIR, 87.DIR, 86.DIR, 85.DIR, and 84.DIR to reflect the year in which the file was created/uploaded). RBBS-PC CPC17-2A Page 155 13.3 Advantages/Disadvantages of FMS Directory ----------------------------------------------- Having a FMS directory has the following advantages: 1. Callers get the newest files listed first. The directory can be displayed EITHER from top to bottom or bottom to top. Reading from bottom up is appropriate when files are in date order and new files are appended to the bottom. When files are alphabetized or grouped some other way, it is more appropriate to read them from the top down. 2. The directory is listed with MORE ([Y],N) or files to download prompts throughout the listing, so at any time the caller may begin downloading, and pick up where they left off in the listing after the download is completed. 3. Wildcard searches on filenames are supported as well as exact matches on strings in the file S)earch command. Whenever a wild card character (* and ?) is specified in the search string, RBBS-PC will automatically shift to matching just the file name. Exact string matches search the full entry rather than just the file name. String searches include extended descriptions for FMS directories, but in non-FMS directories only the first line of the file description is searched. 4. Classification of files is easy. All that is necessary is an editor that produces ASCII files, and a file is classified by a category code of up to 3 characters. To change a file from directory to directory, all that is necessary is to change the category code. No more "erase it here and add it there." 5. No SYSOP maintenance is necessary for new uploads. The caller can classify the upload with a category code, and the SYSOP can specify that the new uploads become instantly available. 6. Complex classifications can be made very simply. A category code is not necessarily the category the caller must type in. The SYSOP can elect to have a classification system where one code that the caller types in will list several different category codes. You can include the file in two directories without having two separate entries. 7. FMS directories can have "headers" (i.e. free text lines not associated with any particular file). This allows things like column headers or help to be included, as well as section headers. A SYSOP may wish to separate a "communications directory" into different sections such as one for QMODEM and one for RBBS-PC. A free text line begins with "*" and is universally displayed if the category code is "***" otherwise it is only displayed when the category associated with the line is selected. 8. Multi-line descriptions (i.e. "extended" descriptions) are supported in both FMS and "old-style" directories. All columns except the first one are available for the description. For FMS directories extended descriptions have the same characteristics as the file that they are associated with. 9. The ability to enter "extended" descriptions for uploaded files is based on the caller's security level (see CONFIG parameter 127). 10. Caller's can list the RBBS-PC file directories with or without extended description. As an example, a caller would enter the command "L - UPLOADS" to list the files in the directory UPLOADS with only one line descriptions. The command "L + UPLOADS" would list the same file with extended descriptions. RBBS-PC CPC17-2A Page 156 11. Archived files can be viewed with the V)iew command when listing FMS directories and the listing will resume where it left off prior to issuing the V)iew command. 12. Individual entries within a FMS directory can be restricted to specific security levels. 13. Comment lines can be included in FMS directories which are never shown to a caller. Often such comments are useful reminders to the SYSOP who is maintaining the FMS directories. 14. Callers can add upload descriptions without actually uploading a file (see CONFIG parameter 153). This is typically useful to the SYSOP. It makes it easy to start an FMS upload directory without having to know anything about its internals or how to use an editor. With the exception of a CORVUS network environment, FMS directories can be updated without taking the system down first. All the caller does is issue the normal upload command. If RBBS-PC finds that the file already exists and that the caller has the necessary security level, RBBS-PC will get the file size and proceed exactly as if the file had just been uploaded. 15. Searches for new files is EXTREMELY fast because RBBS-PC does not have to search all directories if the single FMS directory is in date order (most recent date last) 16. Latest uploads are always shown first, if the SYSOP has elected to make them viewable and the master FMS is in date order. 17. Searches for text will scan the text in the extended multi-line descriptions. 18. Composite categories can be logically constructed out of other categories (see section 13.5). 19. Entries do not have to be physically moved to other .DIR files to be classified as belonging to it. 20. FMS directories can be "chained" to accommodate those multi-user environments, such as Corvus's OMNINET, which will not allow files that change in length to be shared. In such an environment FMS can be used, but the FMS directory must "chain" to the upload directory and their must be a separate upload directory for each node. RBBS-PC CPC17-2A Page 157 Regrettably, the FMS directory also has ONE remaining limitations which may make it unsuitable for all SYSOPs needs. 1. The date must be in MM-DD-YY format. Any single digit number must have a leading zero. If FMS does not totally satisfy your needs, you can use both. RBBS-PC can be configured to look for an old style directory if it does not find a directory in the FMS. If it finds one it will display it. If it does not, it displays the familiar "Directory XXX not found!" message. RBBS-PC CPC17-2A Page 158 13.4 Creating FMS Directories ------------------------------ If you already have separate directories, it would be a good idea to copy all of them into a single one called MASTER.DIR. Detailed directions are given in the documentation for CNVDIR. In DOS this can be done like this: COPY xxx.DIR+xxx.DIR+xxx.DIR... MASTER.DIR where xxx is the name of the old style directories. The 3 dots mean to continue until you have all of the directories you wish to include in the FMS directory. In addition to the "old style" file directories described in section 13.1, RBBS-PC supports two types of FMS "directories" -- multiple, single-subject FMS directories or a single multiple-subject master FMS directory. If there are going to be multiple, single-subject FMS directories, there must also be a "directory of directories" (i.e. a master directory) whose name is specified in CONFIG parameter 211 and there can not be more than 99 of these single-subject FMS directories. If there is going to be a single FMS directory, it's name is specified in CONFIG parameter 214 and it's qualifier is specified in CONFIG parameter 209. An example of multiple FMS directories that assumes the following: CONFIG parameter 220 is "C:\FMS", CONFIG parameter 209 is "DIR", CONFIG parameter 211 is "DIR", and the following files existed: C:\FMS\DIR.DIR C:\FMS\ALPHA.DIR C:\FMS\BEST.DIR The file ALPHA.DIR can be a FMS directory with an alphabetical list of all files and BEST.DIR can be a FMS directory with a date-ordered (latest date last) list of the "best" files. An FMS directory can have an optional "header" line that describes the structure of the directory. RBBS-PC searches FMS directories from bottom to top by default (i.e. the assumption is that they are sorted by date with the newest entry at the bottom). To make an FMS directory read from top to bottom, the directory must have the optional "header" line as the first line. For FMS to read a FMS directory from top to bottom the first four characters in the first line must be "\FMS" and the line must contained the three characters "TOP" (i.e. the whole fixed-length line would read "\FMS TOP"). For FMS directories not sorted by date, the word "NOSORT" must be present in the first line (i.e. the whole line would read "\FMS TOP NOSORT"). The file ALPHA.DIR would have the first line in the file read "\FMS TOP NOSORT". The file BEST.DIR would have the first line in the file read "\FMS TOP" if all searches of the file were to start with the oldest (i.e. first) entry. It is important to realize that FMS directories must have a fixed length in every line. RBBS-PC CPC17-2A Page 159 The columns of all FMS directories are set up as: Column Purpose 1-13 Filename 14-22 File size 24-31 Date in MM-DD-YY format 34- Description + category code To add comments to an FMS directory and not have them shown to the caller, simply begin the comment line with a slash, "\". To force a line to be displayed that is not associated with an FMS directory entry, begin the line with an asterisk and, if it is displayed for only specific categories, the appropriate category restriction. To make an FMS entry visible only to callers with a specific security level or higher, the first character of the file name must be an equal sign, "=". For this entry, the file name is in columns 2 through 13. The minimum security to view this entry goes in column 34 and is followed by a blank and then the description and category code within the columns appropriate for them (based on CONFIG parameter 219). CONFIG parameter 219 specifies the length of the "description" field (40 to 46). The column containing the "category" codes can be variable as follows: Length Columns for description Category code column 40 34-73 74-76 41 34-74 75-77 42 34-75 76-78 43 34-76 77-79 44 34-77 78-80 45 34-78 79-81 46 34-79 80-82 However, some text editors may have a problem with lines 80 or more columns. The fussiest areas for use with FMS are the DATE and CATEGORY CODE fields. These two must be absolutely perfect for FMS to function properly. The others may be slightly more lenient. In order to get the directory in the correct format, insert and delete spaces before and after the column. The file name should not have interior or leading blanks. You must also add a category code to each listing. This is often the most difficult and time consuming part of setting up FMS. A good idea is to format the rest of the directory before you add the codes. CONFIG has a utility, parameter 187, that will check your FMS directory structure for you. If a caller uploads with a "/" for SYSOP, a *** is placed for the category code and only those with a SYSOP security level may view the listing (see CONFIG parameter 125). RBBS-PC CPC17-2A Page 160 13.5 Defining the FMS Category Codes ------------------------------------ In order for FMS to work correctly, the category codes must be defined. This is done in a file specified in parameter 217 of CONFIG. This file is rather interesting in the way it is set up and the possibilities it brings up. The format of this file is, with each line being a separate entry: "<Category name>","<Category codes>","<Category description>" The category name is what the caller types in L;xxxxxxxxxx. The category codes are a list of the character codes in the FMS directory that we want to be under this category name. Category codes can be 1 to 3 characters long, though the simplest and most foolproof method is to make them all exactly 3 characters long. The category description is a short messages that we want displayed when the category is searched for. If the category codes are less than 3 characters in length, blanks must be added to the right to fill out the length to exactly 3 when putting the category codes on the end of file entry. A listing can contain several category codes. This means that a category name of BASIC could have the category codes BSU,BSG,BSS in it. The category codes may be overlapped in several different directories. For example, the BASIC directory used as an example could also have each code included in another directory. UTILS could contain DSU,PRU (Dos utils, Printer utils). GAMES could contain CGG,BSG,TXG (Color Graphics Games, Basic Games, Text games). BASIC could contain BSG,BSS ( Basic Games, Basic Source). SOURCE could contain ACS,BSS (Assembly code source, Basic Source) Such a setup would look like this: "BASICG","BSG","Basic Games" "TEXTG","TXG","Text Games" "COLORG","CGG","Color Graphics Games" "PRINT","PRU","Printer Utilities" "DOS","DSU","Dos Utilities" "ASSEM","ACS","Assembler source code" "BSOURCE","BSS","Basic Source Code" "UTILS","DSU,PRU","Utilities for IBM" "GAMES","CGG,BSG,TXG","Games for IBM" "BASIC","BSG,BSS","BASIC programs" "SOURCE","ACS,BSS","Source code for different languages" The directory might look like: FFIND.ARC 13463 05-24-87 DOS Util look all over disk for file DSU QUEST.ARC 17325 06-02-87 C/G Game D&D style CGG RBBS-SRC.ARC 202562 06-05-87 Source code for RBBS-PC BSS QMODEMSC.ARC 106735 06-07-87 Source code for QMODEM SST PSS BALLOON.ARC 5634 06-08-87 BASIC Balloon game- GREAT BSG STARTREK.ARC 76434 06-10-87 A great game- TEXT TXG When someone lists out GAMES, they get QUEST, BALLOON, and STARTREK. You can also have simply a one to one correspondence, rather than cross referencing by just having one category code for each category. A utility that will help you in setting up your FMS directory is a SYSOP function built into CONFIG. Parameter 187 will test the structure of your FMS directory and diagnose any problems. Be sure to run this utility after you have tried to set up FMS, or whenever you edit the FMS directory file. RBBS-PC CPC17-2A Page 161 13.6 The "Library" Subsystem, CD-ROM, and FMS --------------------------------------------- The RBBS-PC "library" sub-system is highly flexible subsystem that utilizes DOS 'disk subdirectories. The "library" subsystem is not limited to any particular medium. Basically, it relies on three files: CDR.CDR - This is the Directory of Directories just like DIR.DIR is the Directory of Directories for the normal download area. This file is located on the drive and path designated in CONFIG parameter 302, has a file name equal to the extension designated in parameter 303 , and the extension designated in parameter 303. MASTER.CDR - This is an FMS style directory. Highly recommended to have a size of 46 to allow for placing the DISK/AREA number in the last four positions of description. This file is located on the drive and path designated in CONFIG parameter 302. The following is an example of a master directory file, C:MASTER.CDR, that might be used for the "library" subsystem. DEMO.DTA 9841 01-01-80 PRACTICE FORM 680126 READ.ME 256 01-01-80 INTRODUCTORY TEXT FILE 673102 READ.ME 109 01-01-80 INTRODUCTORY TEXT FILE 671102 DK0680 ARC 10-23-87 FORGE VERSION 2.0 200 DK0673 ARC 10-23-87 FREEWAY ...(Disk 3 of 3) 200 DK0671 ARC 10-23-87 FREEWAY ... (Disk 1 of 3) 200 | | | | | | +- 1->13 | | | | | File Name +- 14->22 | | | | File Size | | | | +- 24->31| | | File Date| | | +- 33->76 | | File Description | | 77->79 -+ | DOS | Directory | Number | | 80->82 -+ Category Code The last four characters of the 46-character file description field are used to indicate the "library" pseudo-disk that the file is in. In this way, when a caller lists files, it is self-evident in the description which DOS subdirectory the caller must change to within the "library" subsystem in order to download the file. RBBS-PC CPC17-2A Page 162 RBBS-CDR.DEF - This is the key file to the successful operation of the LIBRARY section. It consists of three fields on each line. "AAAA","BBBBBBBBBBBBBBBBBBBBBB","CCCCCCCCCCCCCCCCCC"cr/lf A - A four position field numbered from 0001 to 9999. This is the DISK/AREA number assigned to a specific group of files. B - This field has no size limit and is a full path to the area excluding the drive: designation. As an example: \1_100\DISK0001 \GAMES\ADVENTUR\DISK1 \A_F\ALPHABET\DISK01\AREA36 C - This field has no length limit but should be kept at around 56 characters to keep from line wrap on the display. It should contain the TITLE of the disk/area. A file containing a description of the library subsystem's category codes must have the name RBBS-CDR.DEF, be in the same DOS subdirectory as the other RBBS-PC ".DEF" files, and look similar: "0671","\601-700\DISK671","FREEWAY Payroll system (Disk 1 of 3)" "0673","\601-700\DISK673","FREEWAY Payroll system (Disk 3 of 3)" "0680","\601-700\DISK680","FORGE VERSION 2.0" The "library" subsystem can be supported without using the FMS. To do this each "directory" would have ".CDR" as it's extension (i.e. GAMES.CDR) -- or whatever extension was designated in CONFIG parameter 303. Typically, the "library" subsystem is used with FMS. When using FMS with the "library" subsystem it is necessary to add categories to the DIR.CAT file. One approach that works well is utilizing categories 1-99 for the normal (i.e. non-library area) downloads and categories 100-200 for the "library" downloads. The basic assumption of RBBS-PC's "library" sub-system is that files are stored in DOS subdirectories on the DOS disk drive specified in CONFIG parameter 301. RBBS-PC CPC17-2A Page 163 13.6.1 How the "Library" Subsystem Works ---------------------------------------- Before it is possible to download from the LIBRARY area it is mandatory that the caller C)hange to the desired library disk. This is accomplished by using the C)hange command from the library menu. RBBS-PC will accept any 1 to 4 digit number (padding the front with zeros to make it a four digit number). RBBS-PC will then search the RBBS-CDR.DEF file (position AAAA only) for an exact match. If no match is found then RBBS-PC indicates that no Library disk has been selected. If a match is found then RBBS-PC will issue a CHDIR command to the drive specified in CONFIG parameter 301 and the path BBBBBBBB that it constructs from the RBBS-CDR.DEF file. RBBS- PC then informs the caller that Disk AAAA CCCCCCCCCCCC has been selected (i.e. "Disk 0680 FORGE VERSION 2.0"). The caller can download individual files from the area selected or A)rchive all the files in the selected area. If the caller decides to A)rchive all the files in the selected area, RBBS-PC will SHELL to the Archive program designated in CONFIG parameter 313 and located in the drive and path designated by parameter 312. RBBS-PC creates an archived file with the name DKAAAA.ZZZ, where AAAA is the disk/area number on the drive and path indicated by CONFIG parameter 304, and ZZZ is the extension, which depends on what archiving program is used. RBBS-PC will then check to see if there are any subdirectories within the selected area. If any exist then RBBS-PC will again Archive the subdirectories and will create ZZZ files with the name DKAAAAa.ZZZ where AAAA is the disk/area number. The designator, "a", is an arbitrary id to differentiate it from the original ZZZ name. If there are more than one subdirectories then the "a" would be replaced by "b", "c", "d", etc. When this is complete the caller is told what files are ready for download. E.g. DKAAAA.ZIP is ready for download. DKAAAAa.ZIP is ready for download. DKAAAAb.ZIP is read for download. As each file is downloaded successfully it is removed from the list and is no longer displayed to the user as ready for download. RBBS-PC CPC17-2A Page 164 13.6.2 The "Library" Subsystem and PC-SIG's CD-ROM -------------------------------------------------- The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K diskette in the PC-SIG library. Sometimes the disk contains all the files already in the ARC format other times they just contain a group of files. The key here is the A)rchive function. The resulting file to be made available for download will NEVER be greater than 360k. This is important since a caller may only have a floppy based system and could not capture a file any larger than a 360k floppy can contain. The PC-SIG's CD-ROM creates the problem of listing both the individual files contained on each diskette as well as a summary description of the individual disks. This can be solved by listing each of the 18,000+ files in the MASTER.CDR using positions 43-76 for the description, positions 77- 79 for the disk drive, and positions 80-82 for the valid categories for downloading. These are contained in the file specified by CONFIG parameter 217. MASTER.CDR might also contain a list of names of the files that would be created by the A)rchive function. This allows the caller to scan a category (i.e. category 200) for disk titles only. Note that the files do not exist until the user uses the A)rchive function. A SYSOP who did not wish to allow individual file downloads might only include these entries in the MASTER.CDR rather than the other 18,000 entries. The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can take up to 10 minutes to search completely (when using a PC at 4.77mhz). If the SYSOP is using FMS, it is recommended that the category file for the normal FMS directory and the category file for the Library FMS directory be the same (PC-SIG has 27 different categories for its files). RBBS-PC CPC17-2A Page 165 13.7 Creating the Personal Files Directory ------------------------------------------ RBBS-PC's "personal" file support is analogous to RBBS-PC's support of "personal" messages in that these files are specially addressed to a specific caller or group of callers based on security. Personal file downloads differ from the general download in three major ways: 1. the time limit check is bypassed in personal downloads, meaning that a qualifying caller can download a file regardless of time left. 2. only files explicitly listed in the personal directory can be downloaded. Normally files to be downloaded will be looked for on the disk(s) where files are available for downloading whether they are listed in a directory or not. 3. only callers with matching user record or sufficient security can download a file. Normally any caller with security enough to issue the download command can download a file. Personal files provide a way that files can be delivered to specific individuals. As an example, a vendor's support bulletin board for a software product might make the upgrade downloadable only by paying customers. A credit reporting corporation can make credit reports electronically available only to the people who order them. Or, a SYSOP can make a file privately available to only one caller. One of the most useful applications for personal downloads is to make certain files available regardless of time remaining. Previously, SYSOPs had to increase the security of callers or set artificially high session limits just to make certain large files available. By putting these file names in the personal directory and limited by security level, these files can be made available regardless of how little time is left. For example, the large files comprising RBBS-PC can be made downloadable to all callers even though they are limited to 30 minutes. Access to personal files can be limited in two ways. First, the files can be downloaded only by callers which have a matching value in their user record. For example, files can be limited by name (any field in the user record can be selected). Alternatively files can be limited by security level, meaning that a file can be downloaded by any person with that security level or higher. File access based on security level can also be accomplished using the standard RBBS-PC file security mechanism, but to do so places the caller's under the standard RBBS-PC constraints of maximum time per session/day. Using the "P)ersonal files" command in the files section, a caller is asked what files the caller wants to download. The only files available to the caller for downloading are those explicitly listed as belonging to the caller, unlike the general download command which will look for any named file on the disk. The caller can ask to List the files available. Callers will see only those belonging to them. There is a special option to download all and only the "new" files specifically addressed to the user by matching a field in the caller's user record. RBBS-PC keeps track of whether the caller has ever downloaded the personal file. When listing, new personal files are marked with an "*" in front of their names (they are "tagged"). Selecting the new files starts a multi-file download for all and only the personal files the caller has never successfully downloaded. RBBS-PC CPC17-2A Page 166 Files you want downloaded ONLY through the personal file features of RBBS-PC should be put in their own subdirectory as specified in CONFIG parameter 142. If you put the personal files in a download subdirectory they would be available then to anyone who could name them. RBBS-PC will search the download areas for a personal file if it is not found in the subdirectory specified in parameter 142. Second, in the same place as the personal files themselves, put in a special personal directory with name specified in CONFIG parameter 143. This directory is the same format as the general file directories of RBBS- PC. The format is as follows: Default Field Positions Length Description of Field 1 - 12 12 The first 12 characters of an entry have the file name, with no internal spaces. 13 - 73 Variable The next group of characters can have anything in them. This will be displayed to the caller who asks for a listing, along with the file name in the first 12 columns. The length of this group is 21 characters plus the length of the upload description specified in CONFIG (40-46, defaults to 40). The default length of this field is 61 characters. 74 -104 Variable The next group of characters are what is used to identify the file as "belonging" to the caller and must match a field in the user record. In CONFIG parameter 43 and parameter 44, the SYSOP specifies the position in the user record to use and how many characters. The default is to begin in column 1 and use 31 characters for the caller's name, but any field in the user record can be used. Optionally, a security can be entered in this last field to limit the file based on the security level of the caller. To use security rather than a match on the user record, simply put a blank as the first character in the field, followed by the security level. 1051 The last character must be an "*" to signify that the file has never been downloaded or an exclamation point if ever downloaded. This personal directory works very much like the File Management System shared directory, using a field in the user record as the category and limiting callers to their one category, or limiting the file to the group of caller's with the minimum required security. The personal directory is fixed length and read in reverse from bottom to top. After setting up or modifying the personal directory, you use the CONFIG utility parameter 187 to check whether the personal directory has the proper format. The personal directory can be created by a text editor (i.e. EDLIN) but be sure to put in the "*" in the last column when creating a new entry so that the file will be tagged as new. Also be sure to make each entry fixed length. If the user's identity does not fill out the length of the last field, be sure to pad the record with blanks out to the full length. When setting up a personal file directory there are seven configuration RBBS-PC CPC17-2A Page 167 options peculiar to personal files: CONFIG Description parameter 43 what part of the user record used to identify files as parameter 44 belonging to the user (beginning column and length), parameter 143 the name of the personal directory, parameter 142 the drive and path where the personal files and personal directory are stored, parameter 144 the protocol that must be used downloading, parameter 147 whether the files downloaded are to be concatenated, and parameter 188 the CONFIG utility to check the structure of the personal directory to make sure it is in the properly format. Parameter 147 and parameter 187 require some explanation of how they might be used. Limiting the caller to a required protocol to use is not something one would generally do. But, for special purpose downloads, like downloading to a printer, one might want to require ASCII, for example. Or, if all callers are to use the same communications package or only a particular protocol is efficient, you can specify what callers must use. Concatenating files means that when multiple files are specified for downloading, the files are sent continuously in one stream of data rather than individually as separate files. In effect, the files are physically combined at the time of downloading. All messages between files are suppressed - the only messages that appear to the caller are those that normally occur when the first file transfer starts and when the last file transfer ends. Concatenation is currently supported only for ASCII downloads. An example of a situation that might use this feature of RBBS-PC is a business that generates short reports for clients. Their clients want to call in remotely to get time-critical reports and print them right in their office on pre-formatted paper. Each report is a separate file on RBBS-PC with all the necessary printer commands already included in each file. A SYSOP might set up RBBS-PC such that the main menu was restructured to make the P)ersonal files function be P)rint reports to reflect the more specialized nature of the board. Callers to this board would call in, identify themselves, and select P)rint reports from the main menu. Callers could use L)ist to see what is available if they are looking for some report in particular; just select all new reports; or ask for a particular report if they must have it immediately. In the last two cases, RBBS-PC would notify the caller to set up to receive and press [ENTER] when ready. The pre-formatted reports with embedded printer control sequences would stream out onto the paper (including formatting like bold or underline) positioning the text to fit in boxes. The paper is automatically advanced as needed. When done, RBBS-PC beeps the user, who then turns the "save to printer" feature off of whatever communications package is being used. To set up this application, the personal file options would be configured to use the caller's id (e.g. account number). The files and directory would be put in a special subdirectory not shared with anything else. The CONFIG parameters would be set to specify that caller's must use ASCII ("A") as their protocol and that multi-file downloads will be concatenated. Another example is that of an electronic job placement service that wanted to limit non-subscribers to a security level 5 with 10 minutes. However, they also want non-subscribes to be able to download a file of potential RBBS-PC CPC17-2A Page 168 employment opportunities that may take more than 10 minutes. The following entries would be put into PRIV.DIR: JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5 /|\ /|\ 12 74 Each record is padded with blanks so that 29 blank characters follow the security level, followed by an '*'. The '*' is not shown in this documentation since it is in a column too far to the right. RBBS-PC CPC17-2A Page 169 13.8 Automatically Checking & Converting Uploaded Files -------------------------------------------------------- Verifying the Integrity of a File --------------------------------- RBBS-PC's on-going commitment to providing the SYSOP with the ability to protect both himself and his callers is reflected in precisely this kind of feature. When a file is uploaded, RBBS-PC will look for a file called T<ext>.BAT (where <ext> is the characters that make up the extension of the uploaded file). RBBS-PC looks for this file on the drive and path specified in CONFIG parameter 105. If this file exits, RBBS-PC will SHELL to either: a.) the program specified in the file (if it only has one line) or b.) to the .BAT file itself. In this way a SYSOP may install whatever processing is desired after a file has been uploaded. If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents of the bat file, passing on the command line the two parameters: a.) the name of the file upload (first) and b.) the name of the file to write the results to (second) If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT file itself, passing a.) the name of the file upload for "[1]" and b.) the name of the file to write the results to for "[2]" as the first and second parameters, respectively. RBBS-PC will consider the upload to have failed and delete the uploaded file, if the file to which the results are to be written has a length greater than 2 bytes. The BAT file should either a.) not write a result file or b.) leave an empty one if the upload is okay. If the file that was uploaded is not okay, the external application should write out some error message more than 2 bytes long. A typical use for this feature of RBBS-PC is to test the compression of the uploaded file and pipe the results to a text scanner that looks for an error string and redirects the output to a file if an error is found. For example if files that are uploaded with the extension .ZIP were to be tested, a SYSOP might create the file TZIP.BAT PKUNZIP -T [1] | FGREP "error in a" > [2] An alternative implementation is: PKUNZIP -T %1 IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2 SETERROR 0 Under versions of QuickBASIC prior to 4.5, programs that reset the error level cause illegal function call 5 upon return from the SHELL. Therefore it is necessary to run a utility to reset the error level back to 0 before going back to RBBS-PC. This is what the SETERROR.EXE file does. RBBS-PC CPC17-2A Page 170 The recommended procedure is to use PKUNZIP, check errorlevel, and reset error level to 0. PKUNZIP outs somehat variable string when different errors occur, making a filter based on text more difficult to implement. Converting Uploads ------------------ RBBS-PC can be configured by the SYSOP to cause uploads with extension <u- ext> to be converted to the default extension <d-ext>. To do this, the SYSOP must put a file named C<u-ext><d-ext>.BAT on the drive and path specified in CONFIG parameter 105. If the file exist RBBS will SHELL to it. Suppose the SYSOP has ZIP as the default extension and wants all files uploaded with the ARC extension to be converted to ZIP formats. 1. A file CARCZIP.BAT would have to exist in the area specified by CONFIG parameter 105. 2. The file CARCZIP.BAT would have exist and drive the conversion. Similarly if the SYSOP also wanted all files uploaded with the PAK extension to be converted to ZIP formats: 1. A file CPAKZIP.BAT would have to exist in the area specified by CONFIG parameter 105. 2. The file CPAKZIP.BAT would have to exist and drive the conversion. RBBS-PC CPC17-2A Page 171 14. SETTING UP ".BAT" FILES FOR RBBS-PC ---------------------------------------- Many SYSOPs have set up batch files to invoke RBBS-PC automatically and to re-invoke RBBS-PC should there be a power outage. These files range from the simple to the sublime in terms of complexity. In a multiple RBBS-PC environment, these .BAT files CANNOT BE SHARED. If you are going to exit RBBS-PC and transfer control to DOS remotely (either via the SYSOP function 7 or via "doors"), it is necessary that: 1. RBBS-PC be executed from a batch file. 2. The batch file which is executing RBBS-PC contain an "IF" statement that checks for the existence of the batch file which RBBS-PC dynamically builds when either "doors" or SYSOP function 7 is invoked. 3. Within the "IF" statement, the logic exists such that the batch file dynamically built by RBBS-PC for the "doors" functions or SYSOP function 7 will be invoked if it exists. As a very simple example, let us assume that: 1. the batch file that invokes RBBS-PC is named A:RBBS.BAT, and that is what was entered for parameter 104 of CONFIG, 2. the name of the batch file that RBBS-PC will build dynamically for either "doors" or SYSOP function 7 is A:RCTTY.BAT, and that is what was entered for parameter 103 and 3. the compiled version of RBBS-PC is being executed and is named RBBS-PC.EXE and is on the default disk drive. 4. you have elected to use the watchdog utility program. 5. COM1 was designated as the communication port to be used by RBBS-PC. 6. the CALLERS file is on drive A. Then A:RBBS.BAT (in a non-MultiLink environment) would contain the following: IF EXIST A:RBBSxF1.DEF DEL A:RBBSxF1.DEF IF EXIST A:RCTTY.BAT DEL A:RCTTY.BAT RBBS-PC x filename (see note of values available for "x" and "filename") IF EXIST A:RBBSxF1.DEF GOTO EXIT IF EXIST A:RCTTY.BAT A:RCTTY.BAT A:RBBS.BAT :EXIT NOTE: When running RBBS-PC.EXE, RBBS-PC will check for the "x" in the command line that invoked RBBS-PC. The "x" on the execute line is extremely important to the correct operation of RBBS-PC. If you are running in a local area network environment then the "x" should be a number between "1" and "0" or a letter between "A" and "Z". If "x" is omitted from the command line, RBBS-PC will look for a file named RBBS- PC.DEF. RBBS-PC uses the parameter in the command line to determine the correct RBBSxPC.DEF file to use for its configuration parameters if the second parameter is not present. If the second parameter is present, then RBBS-PC assumes this is the fully qualified file name for the .DEF file that this node should use. RBBS-PC CPC17-2A Page 172 15. THE USE OF RBBS-PC "DOORS" ------------------------------ The RBBS-PC "door" concept is that of allowing a SYSOP to set up a "door" through which users can exit from RBBS-PC and enter other applications. In previous versions of RBBS-PC (i.e. prior to CPC12-3A) this had been called "windows" but because of the confusion this created with the WINDOWing concepts of other software, it has been re-labeled "doors". 15.1 "DOORS" Are Nothing More Than .BAT Files --------------------------------------------- RBBS-PC's "doors" are nothing more than .BAT files that the SYSOP has created to allow users to exit from RBBS-PC and enter other applications (i.e. databases, etc.). The SYSOP is responsible for writing the .BAT files that users will be allowed to invoke. Assuming that RBBS- PC is brought up by DOS via an AUTOEXEC file that invokes RBBS.BAT, a door called EDIT exists that consists of a .BAT file (EDIT.BAT) which contains the commands CTTY, EDLIN, and RBBS.BAT. In order to exit RBBS-PC (either for a "door" or for the remote SYSOP function 7) without the code that the BASIC compiler generates for you dropping the remote user, it is necessary for the compiler that RBBS-PC is compiled under be "patched" as described in Appendix T otherwise the user will be disconnected upon returning to RBBS-PC. Here is pictorially what happens: DOS | RBBS.BAT <---------------------------------+ | | \|/ | +--------->RBBS-PC.EXE | | | \|/ | "RUN" | | | +<-------------ends | | | RBBS.BAT | | | \|/ | RCTTY.BAT (invokes door called "EDIT") | | | \|/ | EDIT.BAT | | | +--------->EDLIN.COM | | | EDIT.BAT <--------ends | | | \|/ | RBBS.BAT | | | \|/ | +--------->RBBS-PC.EXE | | | welcome back from door | and RBBS-PC continues-------->| RBBS-PC CPC17-2A Page 173 15.2 A Sample .BAT File for a "DOOR" ------------------------------------ A sample .BAT file for a program called TEST.EXE that assumes: 1. That you are going to be using COM1. 2. That the program "TEST.EXE" is on the default drive. 3. That the batch file to invoke RBBS-PC is called "RBBS.BAT." 4. The batch file "RBBS.BAT" is on the default drive. 15.2.1 Redirect I/O Using the CTTY Method ------------------------------------ Would look like this using the CTTY METHOD: CTTY COM1 TEST.EXE CTTY CON RBBS.BAT The first command, "CTTY COM1", assigns most standard input and output to the communications port number 1. The second command, "TEST.EXE", invokes some test program that you write that reads from and writes to the standard input and output devices (i.e. the keyboard and the screen). The third command, "CTTY CON", reassigns the standard input and output back to the local PC's keyboard and screen whenever TEST.EXE ends. The fourth command simply invokes another batch file named RBBS.BAT (which presumably invokes RBBS-PC). 15.2.2 Redirect I/O Using the CTTY Method ------------------------------------ Would look like this using the REDIRECT I/O METHOD: COMMAND /C TEST.EXE <COM1 >COM1 RBBS.BAT The first command, "COMMAND /C TEST.EXE <COM1 >COM1", starts a secondary command processor, loads TEST.EXE and assigns most standard input and output to the communications port number 1. "Most" is the key word here since PC-DOS does not have a way of redirecting "STANDARD ERROR" like it does for "STANDARD IN and STANDARD OUT". To solve this problem STDERR.COM is included as part of the basic RBBS-PC system. This program was provided by Quarterdeck Systems. Run "STDERR.COM" one time only before you start RBBS-PC. I suggest that you include it in your AUTOEXEC.BAT file. This program works with all versions of PC-DOS 2.0 through 3.2. A sample "DOOR" might look like this using the DEVICE DRIVER METHOD: CTTY GATE1 TEST.EXE RBBS.BAT The first command, "CTTY GATE1", assigns most standard input and output to the device drive named "gateway". Since it is a device driver it must exist in your CONFIG.SYS. The second command, "TEST.EXE", invokes some test program that you write that reads from and writes to the standard input and output devices (i.e. the keyboard and the screen). The third command, "CTTY CON", reassigns the standard input and output back to the local PC's keyboard and screen whenever TEST.EXE ends. The fourth command simply invokes another batch file named RBBS.BAT (which presumably invokes RBBS-PC). RBBS-PC CPC17-2A Page 174 15.3 Setting Up and Testing a "DOOR" ------------------------------------ To first set up and test a door, DO NOT USE RBBS-PC. Rather set up with 1. your modem on auto-answer (i.e. it answers the phone) 2. a .BAT file that redirects all input and output to the communications port that you are going to use using the IBM DOS CTTY command. 3. make sure the .BAT file invokes the program that you want to use as a "door." 4. invoke the .BAT file that you set up in steps 2 and 3. 5. dial up the modem that you set in auto-answer mode in step 1. 6. get your "door" to work in this environment. If you have problems with steps 1 through 6, call your friendly IBM support or the vendor of the software that you want to use as a door and ask them to teach you about either their software or the CTTY command and their software's compatibility with the CTTY command. AFTER YOU HAVE YOUR DOOR WORKING, to set up a "door" for RBBS-PC, you must 1. list the name of the door (i.e. the .BAT file which you already got working and debugged and are responsible for setting up) in MENU5 (or whatever name specified in CONFIG parameter 102 for the text file containing the menu of available "DOOR"s). 2. indicate that doors are available (via CONFIG's parameter 101). When a user invokes the D>oor command, RBBS-PC will: 1. List MENU5, 2. Check that the door that the user selects was specified in MENU5, 3. Check that the .BAT file exists (on the default drive), 4. Dynamically create a .BAT file with the name specified by the SYSOP in parameter 103 of CONFIG that: a. invokes the .BAT file of the window specified,and b. re-invokes RBBS-PC after the user EXITS from the "door" by invoking the .BAT file that the SYSOP specified in parameter 104 of CONFIG. The purpose of "doors" is to allow for the "horizontal" growth of RBBS- PC. In order to not limit the application of RBBS-PC either to BASIC or the current compiler, "doors" was chosen as a mechanism to allow SYSOPs to make available other features (i.e. databases, games, etc.). Hopefully with RBBS-PC as a base, the limitations on doors will only be the SYSOP's resourcefulness AND IBM'S DISK OPERATING SYSTEM (see Appendix W)! The design of the .BAT file that is to be used as a "door" is critical and is the responsibility of the SYSOP. At the very minimum it should handle the communication port I/O. This can be done in a very primitive way using the DOS CTTY command as described in section 15. When the file RCTTY.BAT is executed, it executes another batch file with the name of that particular door. DOS does not return to the RCTTY.BAT. So, at the end of your doors batch file, you must reinvoke RBBS.BAT. RBBS-PC CPC17-2A Page 175 The way that "doors" works is to check to see if the door name specified is in MENU5. If it is in all capital letters in the RBBS-PC file MENU5, it runs the batch file of that name with the extension ".BAT". In general, the program invoked as a "door" has to do is print everything to the communications port and if you wish, echo it to the screen. The initial part of any "door" should read in the parameters passed to the "door" in the "node" record and establish the communications parameter appropriately. Alternatively, "DOORS" can be invoked via a control file, see CONFIG parameter 109. RBBS-PC CPC17-2A Page 176 15.4 Invoking "DOOR"s Via The External Control File --------------------------------------------------- In addition to simply invoking "DOOR"s using the standard approach outlined above, RBBS-PC allows a multiplicity of "DOOR"s which may require different methods and parameters to be used when invoking them. CONFIG parameter 109 allows the SYSOP to specify the name of this control file. This approach allows different "DOOR"s to be invoked in different ways. Specifically, the SYSOP can tailor the way each "DOOR" is invoked as follows: 1. The minimum security level to invoke each "DOOR" may be different. 2. The caller may be required to answer a questionnaire before the "DOOR" is invoked. This is extremely useful if the "DOOR" is a database search program and the questionnaire gathers the necessary search criteria from the caller prior to invoking the "DOOR". 3. The "DOOR" may be either SHELLed to (i.e. where RBBS-PC remains in memory and the "DOOR" is simply loaded in with RBBS-PC) or EXITed to (i.e. where RBBS-PC terminates itself and releases the memory it uses for the "DOOR" to be loaded into). 4. The "DOOR" may be invoked via a "template" (see section 21.2) and information passed to the "DOOR". "Templates" are useful when passing information from a questionnaire to a database search program. RBBS-PC normally passes the node ID as the first parameter to a "DOOR". When using a "template" to invoke a "DOOR" the "template" must include the parameter "[NODE]", if the node ID is to be passed to the "DOOR". 5. A file may be specified for RBBS-PC to display to the caller upon returning from a "DOOR". This file may be created by the "DOOR" that was invoked (i.e. the output of the database search and retrieval) or simply a text file that the SYSOP created. 6. Additionally, when returning from each "DOOR" the SYSOP can elect to ask the caller to re-enter their password as an added security verification. 7. Finally, the control file approach to invoking "DOOR"s allows the SYSOP to specify the maximum amount of elapsed time that a caller can spend in each "DOOR". If amount of time remaining that the user has on the system is greater than the amount of time allowed in the "DOOR", the smaller of the two time's is used. As with all features, the control file approach to invoking a "DOOR" is optional. However, even if it is used a "DOOR" can only be invoked by a caller if a .BAT file exists (see section 15.3). RBBS-PC CPC17-2A Page 177 15.5 EXITing or SHELLing to "DOOR"s ----------------------------------- There are two ways to execute other programs from RBBS-PC: 1. EXITing RBBS-PC and invoking the other program via a .BAT file that RBBS-PC builds dynamically, or 2. SHELLing to the other program while RBBS-PC remains in memory. EXITing RBBS-PC allows other BASIC programs to be run as external programs to RBBS-PC, conserves memory, and allows all of RBBS-PC's features to be active in computers with only 320K of memory. The "price" that is paid is that upon returning from the externally called program RBBS-PC's .EXE file must be reloaded into memory. Unless a control file is used to invoke "DOOR"s, RBBS-PC always EXITs to "DOOR"s. SHELLing prohibits other BASIC programs to be run as external programs to RBBS-PC, consumes memory because RBBS-PC remains in memory when the other program is running, and requires 386K of memory (under DOS 3.2) to activate all of RBBS-PC's features. However, SHELLing does eliminate the need to reload the RBBS-PC.EXE file each time. RBBS-PC CPC17-2A Page 178 15.6 Resetting The User's Record Via a "DOOR" ---------------------------------------------- WARNING -- this is an extremely powerful feature! It opens up everything in the user record to modification by the "DOOR". The "door" must also have knowledge of where fields are in the user record and may cease to work properly when the user record changes its format. The main application for this is feature within RBBS-PC if for "DOOR"s that maintain certain SYSOP- defined fields. For a "DOOR" to reset any part of the user record all a door has to do is include in DOUTx.DEF file, where x is node number, a line in the format UR(<start>:<end>),<value> where: <start> is the beginning byte in user record, <end> is the number of bytes to revise, and <value> is what goes into the specified position in the user's record. For example, UR(63:24),"City,State" would update the city/state field with the value "City,State", setting 24 bytes in user record to that value (blank fill to right), beginning with character position 63. The "UR" request only works for data stored in character format in the user record. RBBS-PC supports a second request in the form SL,<sign><value> where "SL" stands for security level. <sign> can be nothing, plus, or minus, and means respectively to set the security level to the following value, or to raise or lower the security by the amount specified. For example, "SL,6" requests that the security be set to 6 whereas "SL,-2" means to lower the security by 2. RBBS-PC CPC17-2A Page 179 15.7 A Summary of "DOOR"s ------------------------- Finally, if the preceding discussion of "doors" is a complete mystery to you, contact a SYSOP of an RBBS-PC that is using "doors" and ask for help. TRADEWARS is one of the more professional "doors". It was written by John Morris, who can be reached via his RBBS-PC data number (702) 673-3387. If you call people to take up their time learning about "doors" for personal gain (i.e. you are a consultant or some company's employee being paid to write a "door") have the courtesy to tell them. The "user helping user" concept does NOT imply that anyone should be taken advantage. Anyone who has acquired specialized knowledge has the right to be remunerated for their efforts if their knowledge is being used to further commercial purposes and they request it. The "door" concept stretches IBM's DOS' capabilities and requires an knowledge of how both DOS, the DOS CTTY command, and .BAT files work. RBBS-PC CPC17-2A Page 180 16. THE SECURITY FEATURES OF RBBS-PC ------------------------------------- RBBS-PC has always been an open system designed for public use. A SYSOP should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive safeguards that systematically enhance security and privacy. For example, RBBS-PC has the logic within it's code to prohibit anyone (including the SYSOP) from downloading the RBBS-PC "system" files described in section 5.1. RBBS-PC can still be run as a wide-open system, but the SYSOP has many additional options to restrain access. These security options make RBBS-PC much more suitable for private and business use. RBBS-PC's security is controlled by three things: 1. the system configuration file (RBBS-PC.DEF), 2. the two external security files for a. passwords (PASSWRDS), and b. file downloads (FILESEC), and 3. the users file (USERS) in which each user has an assigned security level. The users file is controlled by the SYSOP user maintenance function 5 as described in section 17. To change a specific users security level you select the M>odify option and then the S>ecurity option. This allows you to set the security level for a user. Users cannot set their own security levels. Section 16.3 describes how to implement special passwords that provide special privileges to the groups that issue them. Section 16.4 describes how specific files, groups of files, or even whole disk volumes can have download security levels associated with them. RBBS-PC CPC17-2A Page 181 16.1 RBBS-PC's Security Features -------------------------------- Each user has an assigned security level, permitting over 65,000 possible security levels. Each command in RBBS-PC also has a security level assigned to it. Security assignments are controlled by the SYSOP. To use a command, the caller's security level must be at least as high as the command's security level. The SYSOP can assign a file or group of files both a security level and a password. To download a file, a caller must have a security level at least as high as the file's and be able to give the file's password (if one is present). All users must pass these security tests, including anyone with SYSOP privileges. Messages can now be assigned a password by their creator. Then only persons who are able to give that password can read or kill the message. Messages with password protection will show <PROTECTED> when scanned. Callers have no way of distinguishing messages to private individuals and to groups except by how they are addressed. Persons with SYSOP privileges can read all messages. Section 16.2's description of sending a message to an AUTHORS SIG as an addressee with the password of AUTHORONLY shows how to send a message to a special group. Security violations are logged to the CALLERS file. These include attempting to use functions without sufficient security clearance, and failure to give required passwords. RBBS-PC's default configuration is that of an "open" system. RBBS-PC's security system provides the SYSOP with several choices on how to run RBBS-PC. The chief ones are as follows: 1. Change the bulletin board from an open system available to all callers, to a pre-registered system available only to specified users. To support this option, there is a function in the SYSOPs user maintenance option 5 to ADD users. 2. A SYSOP can set up different "classes" of users by assigning different security levels to different users. Concurrently the SYSOP would have to assign different security levels to different commands. For example new callers might be permitted only to leave a comment, read bulletins, and list files that can be downloaded. Or there might be a group of files assigned a security level that only members of a special interest group can download. 3. The SYSOP can segregate the functions of the bulletin board into different groups based on a password. A specific file or group of files can be downloadable only to those who knew the password. Similarly, messages can be made open to everyone knowing the password but closed to everyone else. This way there can be semi-private portions of the bulletin board. RBBS-PC CPC17-2A Page 182 16.2 Examples of Uses for RBBS-PC's Security System --------------------------------------------------- Some examples of how a SYSOP can tailor RBBS-PC using RBBS-PC's extensive security features follow. SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group wishes to run a RBBS-PC for both the general public and its own use. An example would be an authors SIG for persons interested in publishing books and articles or developing commercial software. A definite need would exist to be able to address messages to everyone in the SIG without making them open to every caller. The SIG would establish the convention to password protect general SIG messages with the password AUTHORONLY, and to address them to AUTHORS SIG. Another example would be a bulletin board devoted to the exchange of software. Allowing persons to use the message subsystem would only interfere with the primary purpose of the bulletin board. Therefore the SYSOP removes from the menu the functions for leaving and reading messages. To prevent a person from using the functions to leave or read a message (even though they are not displayed), the SYSOP assigns these functions a security level higher than a person who logs on normally would be assigned. Another example of using RBBS-PC's security system would be to set up an agreed upon temporary password such that when a user logs onto the system they can issue the password and get longer than normally allowed. If the time for normal users is 30 minutes, the SYSOP can set up the special password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the normal 30. By shifting over to this special password after logging in, members can get extra time if they need it. SOFTWARE SUPPORT -- An author of a freeware program offers RBBS-PC support to all persons who register their copies and send a contribution of, say, $35 per copy. The registered user can get answers for problems and download free updates and sample applications. The author wants anyone to be able to call just to find out about the service. New callers get a security level of 2 automatically assigned to them. This allows them to use only the message subsystem. The file subsystem is assigned a security level of 7. Contributors are added by the SYSOP with a security level of 7 and a pre-assigned password. Except for SYSOP functions, registered users have free reign in the RBBS-PC. CLIENT SUPPORT -- A SYSOP on a public RBBS-PC also works as a management consultant. She has several associates who work with her on projects. She needs to be able to send and receive messages from her associates which the general public should not see. So they agree on a message password NOTPUBLIC. To support her different clients she also needs to leave private files for downloading. To each client she assigns a special downloading password. To restrict downloading to just that client, file names are put in the file security file with the appropriate password. Only persons with the password can then download them. RBBS-PC CPC17-2A Page 183 PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its regional offices. Only regional vice-presidents should be able to download certain management reports. In file security these reports are assigned a high security level of 9, which only managers get. RBBS-PC CPC17-2A Page 184 16.3 How to Implement the Password File --------------------------------------- CONFIG allows the SYSOP to designate the name of the file containing the privileged group passwords to RBBS-PC. Since this file is a normal ASCII file, the SYSOP can use any text editor to create and update the file. Put the information for each password on a single line and separate the fields with commas. It is important to note that EACH record of the password must contain ELEVEN parameters (i.e. TEN commas). For the password file, the format is: parm1,parm2,parm3,parm4,parm5,parm6,parm7,,parm8,parm9,parm10,parm11 where: parm1 -- password that this line applies to parm2 -- level> security level for password, if any, or if no password, then security level this line applies to parm3 -- maximum time in minutes for a single session parm4 -- maximum time in minutes per day parm5 -- number of days in the subscription period parm6 -- start time, in format HHMM 24 hour style,parameters apply parm7 -- end time, in format HHMM 24 hour style, parameters apply The start/end time are limits on all other parameters: meaning that they apply only during the specified times. Specifying no start/end times means that the rest applies all day. parm8 -- the type of ratio method to use. This should be one of the following: '0' - meaning use the files uploaded to files downloaded ratio '1' - meaning use the bytes uploaded to bytes downloaded ratio '2' - meaning use the files per day restriction '3' - meaning use the bytes per day restriction NOTE: FIRST TIME CALLERS MUST UPLOAD AT LEAST ONE FILE (BYTE) BEFORE DOWNLOADING UNLESS THEY ARE: EXEMPT FROM THE RATIO REQUIREMENTS, ARE USING THE DAILY RATIO METHOD, OR AN INITIAL UPLOAD CREDIT HAS BEEN GRANTED. THE INITIAL CREDIT FIELD IS IGNORED FOR METHODS 2 AND 3. parm9 -- the ratio field. This must be any number greater than zero where '0' means this security level is exempt from a ratio requirement. A positive integer, such as 15, placed in this parameter requires that the caller maintain a ratio of a least 1 file (or byte) uploaded for every 15 files (or bytes) downloaded. The ratio of uploads to downloads can be cumulative over multiple days or it can be limited to the current day's activities of the caller. parm10 - the initial credit field. This can be any positive integer including zero. The use of ratio methods 2 and 3 in conjunction with this field can restrict the number of files (or bytes) that can be downloaded by an individual or group of callers per day. parm11 - the elapsed time (in seconds) that a caller must wait after logging on before either "doors" or file downloading (either, neither, or both) are permitted to the caller. See the description of CONFIG parameter 155 in section 11.8 for a fuller description of how this RBBS-PC option functions. Here are some examples of how the PASSWRDS file might be used: RBBS-PC CPC17-2A Page 185 ,5,50,,,0001,0600,,, Security level 5 gets 50 session minutes ,5,25,,,,,,,, between 00:01 AM and 6 AM, and 25 minutes otherwise. ,7,50,70,730,,,,,, Security level 7 has a subscription period of 2 years and a session limit of 50 minutes, and a daily limit of 70 minutes. BIGTIME,6,52,,,,,,,, Temporary password BIGTIME gets 52 minutes per session and a security of 6. EXTEND,5,120,,9999,,,,,, Temporary password EXTEND gets 120 minutes for the current session (the user's elapsed time per day would still remain whatever was set in CONFIG parameter 8), a temporary security level of 5, and a subscription period of 9,999 days. ,7,128,256,,,,,,,120 Users who log on with a security level of 7 are automatically granted 128 minutes on the system for each session, 256 minutes total for each day (independent of what was set in parameter 8 of CONFIG), and their subscription period remains unchanged from whatever it was before, but they must wait 120 seconds before being able to exit to a "door" or download a file. SKIPRATIO,170,120,200,90,0600,1200,0,0,, Temporary password 'SKIPRATIO' grants the caller a security level of 170, a session limit of 120 minutes, a daily time limit of 200 minutes, a 90 day subscription period, during the hours of 6AM until noon with no ratio limits. ,140,60,60,365,0001,2400,1,10,, Users with a security level 140, have a session limit of 60 minutes, a daily limit of 60 minutes, a one-year subscription, but during any hour of the day they must maintain a ratio of 1 byte uploaded for every 10 bytes downloaded. There is no initial upload credit. Therefore, an upload must take place before a download. ,150,70,,90,,,0,15,2,3600 Users with a security level of 150, have a session limit of 70 minutes, a 90 day subscription, must maintain a ratio of 1 file uploaded for every 15 downloaded. An initial credit of 2 files are granted to all new/existing users. However, they can not exit to a "door" or download a file for one hour (3,600 seconds). ,165,90,,120,,,0,30,, Users with a security level of 165, have a session limit of 90 minutes, a 120 day subscription, must maintain a ratio of 1 file uploaded for every 30 downloaded. No initial upload credit is granted. ,170,120,,365,,,2,10,, RBBS-PC CPC17-2A Page 186 Users with a security level of 170 have a session limit of 120 minutes, a one-year subscription limitations, but can only download 10 files per day. ,200,360,,730,,,3,250000,, Users with a security level of 200 have a session limit of 360 minutes, a two-year subscription, but can only download 250000 bytes per day. If you are using COPY CON to create this file you "MUST" press F6 followed by a Ctrl/Z at the end of the last entry prior to pressing carriage return. RBBS-PC CPC17-2A Page 187 16.4 Implementing Security for Download Files ---------------------------------------------- CONFIG allows the SYSOP to designate the name of the file containing the passwords and security levels that can be used to restrict downloads of specific files, volumes, or files names meeting certain "wildcard" criteria. This file contains file names with download restrictions in the format: <filename>, <security level>,<password> Note: Each line is a record and ends with carriage-return line-feed. The only optional field is the password field for a filename. By leaving the password field empty, no password is assigned to a file. The commas between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE even if you do not have a password associated with the file. Some examples would be: COMMAND.COM, 10,DOS PAYROLL.DAT, 99,BANKRUPT CALLGIRL.SEX,,ILLEGAL \FINANCE\STOCKS,100, The file COMMAND.COM could not be downloaded unless a user had a security level equal to or greater than 10 AND could supply the password "DOS". The file PAYROLL.DAT could not be downloaded unless a user had a security level equal to or greater than 99 AND could supply the password "BANKRUPT". Any user could download the file CALLGIRL.SEX if they could supply the password "ILLEGAL". Any user with a security level of 100 or higher could download the file STOCKS in the DOS subdirectory FINANCE without supplying any password. Additionally "wild-card" characters and drive designators can be used to protect or restrict certain classes of files (by extension, by drive, etc.) from being downloaded. Some examples would be: A:*.*,8, E:*.SEC,2,PW1 A*.M*,0,GX3 XY?X.*,9,3XG All files on drive A would require the users to have a security level of 8 in order for a user to download them. Any user who wanted to download a file whose extension was ".SEC" and was found to be on drive E would have to not only have a security level of at least 2 but to also give the password PW1. The third entry above would require a user who wanted to download any file on any drive with a prefix that began with "A" and an extension that began with "M" to have a security level of at least 0 and to enter the password GX3. Finally, the last entry above would require any user who wanted to download any file on any drive whose four-letter name began with "XY" and whose last letter was "X" with any extension to have a security level of at least 9 and enter the password 3XG. The wildcards "*" and "?" operate just like they do in DOS with one exception. The "?" requires a character. In DOS the name "HAPPY" satisfies the file specification "HAPPY?" but it does not in RBBS-PC. To get exceptions to the general rule, just put the exceptions first. RBBS-PC's file security search stops with the first applicable entry that it encounters. For example, RBBS-PC CPC17-2A Page 188 1. if you want all files on the B drive to require the user to have a security level of at least 3, 2. except that files on the B drive with the extension ".SEC" would require the user to have a security level of at least 6, and, 3. regardless of the disk drive that they were on, any file beginning with "MES" with an extension of ".SEC" would require the user to have a security level of at least 12 you would enter the following into the file security file MES*.SEC,12, B:*.SEC,6, B:*.*,3 Special Note:RBBS-PC is hard coded so that there are some files that nobody can download -- not even the SYSOP. These are RBBS-PC.DEF, users, messages, callers, group password, comments, the file security, and backup files. Similarly the batch files that control RBBS-PC and let the caller exit to DOS 2 can not be downloaded. The default security file provided with RBBS-PC is empty. RBBS-PC CPC17-2A Page 189 16.5 Implementing Security for RBBS-PC Commands ------------------------------------------------ RBBS-PC allows each command to be assigned it's own security level. A user who wishes to invoke an RBBS-PC command must have at least the same security level as the command. Let's assume that a SYSOP wants to set up the following classes of users: Classification of Users Security Level "Locked Out" Users 0 New Users (first time) 1 Normal Users 2 Users who can "view" a Conference 3 Users who can enter Messages 4 Users who can download files 5 Users who can upload files 6 Users who can Join a Conference 7 Users who can do some SYSOP commands (Jr. SYSOP's) 8 Users who can enter a "door" 9 Users who can enter all SYSOP commands (Co-SYSOP's) 10 The following table illustrates one method of assigning each RBBS-PC command it's own security level: Security Level Subsystem/Command Assigned to Command Messages Subsystem A>nswer questionnaire............... 4 B>ulletins.......................... 1 C>omments........................... 1 D>oor subsystem..................... 9 E>enter message..................... 4 F>iles system....................... 1 I>nitial welcome.................... 1 J>oin a conference.................. 7 K>ill messages...................... 4 O>perator page...................... 1 P>ersonal mail...................... 2 R>ead messages...................... 2 S>can messages...................... 1 T>opic of messages.................. 1 U>tilities (more)................... 1 V>iew conference mail............... 3 W>ho's on other nodes................3 @>Library Sub-System.................1 Files Subsystem D>ownload........................... 5 G>oodbye............................ 0 L>ist file directories.............. 4 N>ew files.......................... 5 P>ersonal downloads................. 5 S>earch directories for string ..... 1 U>pload a file...................... 1 V>erbose listing of ARC file........ 1 Utilities Subsystem B>aud rate.......................... 1 C>lock (time of day)................ 1 E>cho selection..................... 1 F>ile transfer protocol............. 1 G>raphics........................... 1 RBBS-PC CPC17-2A Page 190 L>ength of page..................... 1 M>essage Margin..................... 1 P>assword change.................... 1 R>eview preferences................. 0 S>tatistics of system............... 1 T>oggle (line feeds, etc.).......... 1 U>serlog............................ 2 Library Subsystem A>rchive a Library disk..............5 C>hange a Library disk...............5 D>ownload........................... 5 G>oodbye............................ 0 L>ist file directories.............. 4 S>earch directories for string ..... 1 V>erbose listing of ARC file........ 1 GLOBAL commands ?>What can be done.................. 1 H>elp with a command................ 1 Q>uit to another subsystem or exit.. 1 X>Expert/novice toggle.............. 1 SYSOP Subsystem 1>List comments..................... 8 2>List callers log..................10 3>Recover a Message................. 8 4>Erase comments.................... 9 5>USERS maintenance.................10 6>Toggle page bell.................. 8 7>Exit to DOS 2.x or above.......... 9 RBBS-PC CPC17-2A Page 191 16.6 Beware of the "Trojan Horse!" ----------------------------------- Despite RBBS-PC's security always remember that you should always assume: "EVERY FILE ON THE PC RUNNING RBBS-PC CAN BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!" RBBS-PC's security system appears to be so fool-proof that some individuals have resorted to uploading programs that appear to do one thing, but actually do something else. These "trojan horse" programs search all the disks that are connected to the PC that the program is running on for such RBBS-PC files as RBBS-PC.DEF or USERS. The program then copies these files to an innocuously named file that can be downloaded later when the person who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the pseudonym that the SYSOP can use to logon on remotely as the SYSOP, once the user downloads a copy of it the user can then log on as the SYSOP and do just about anything including exiting to DOS and formatting all the disks on the system. Similarly, the USERS file contains passwords and the security levels of everyone on your RBBS-PC -- some of whom may have SYSOP privileges. You can protect yourself against anyone logging on as you, the SYSOP, by not allowing anyone to logon as the SYSOP remotely. To do this read section 11 regarding parameter 121. You can protect yourself against unauthorized access of the USERS file by simply not allowing any user to have SYSOP privileges. Of course there is the "trojan horse" program that doesn't even bother with the above, but simply destroys all the disk files on all the disks that are connected to the PC that is running the program. See the rest of section 22 to see how you can protect yourself against such programs. RBBS-PC CPC17-2A Page 192 17. SYSOP FUNCTIONS ------------------- The SYSOP functions are not available to the general user. They consist of numeric commands 1-7 for SYSOPs that sign-on remotely as well as some of the keys on the keyboard attached to the PC that is running RBBS-PC when the SYSOP signs on "locally" by pressing the "Esc" key. When on "locally", the SYSOP should not use some of the user functions that depend on the person invoking them being remote (i.e. file transfers, changing baud rate to 450 baud, etc.). To enter the SYSOP mode locally press the ESC key on the PC that is running RBBS-PC itself and enter the special pseudonym you assigned yourself as the first and last name in order to log on as the primary SYSOP from a remote terminal. 17.1 SYSOP Commands Within RBBS-PC ---------------------------------- The following operations can then be performed by entering a number only at the command prompt: 1 - Type COMMENTS file. The contents of the COMMENTS file is displayed. This file can also be inspected using a TYPE command from DOS. It is a ASCII sequential text file. 2 - Type CALLERS file. A log is maintained of all persons who have called the system. This function will list the file showing the users name and the date and time signed on as well as the names of the files they upload/downloads along with any security violation or errors encountered. This is a random access file of 64-byte records. 3 - Resurrect a message. This function will return a message that has been killed to an active state. If message file has been "packed", the killed messages are no longer recoverable. The function will ask for the message number of the message to be recovered. 4 - Erase the COMMENTS file. This function will erase the comments file by killing the file. Since the file is opened "APPEND," a new comments file will be created the next time a user leaves a comment. 5 - USERS file maintenance. The users file contains entries for each user registered with the system. This function permits the SYSOP to A)dd -- add a user to the USERS file. L)st -- list the USERS file. P)rt -- print the USERS file on the printer. M)od -- modify a record in the USERS file. S)can - scan each record in the USERS file for a particular string. In <M>odify mode, limiting editing of the users record in the USERS file can be done. The following subfunctions are available: D - Delete a user in the USERS file. F - Find a user in the USERS file. M - Return to the option 5 function prompt. N - Give the user a new password. P - Toggle the printer flag to print entries on the printer. Q - Quit and return to the main message prompt. R - Reset the users graphic mode. S - Set the security level of the user. This can be used to lockout or grant special privileges to the user. # - locate any record number within the USERS file. RBBS-PC CPC17-2A Page 193 In <M>odify mode a record will be displayed followed by a subfunction prompt for action. To get to a specific record the record number can be entered at the prompt and if valid that record will be displayed. If the record number is invalid or an empty c/r is entered then the next record in the file will be displayed. 6 - Toggles the operator page bell on/off. This overrides the "office hours" specified in the RBBS-PC.DEF file. 7-SYSOP drop to DOS as a remote user. If the SYSOP has logged on remotely and is running RBBS-PC under DOS 2.0 or greater, this function will dynamically setup a batch file to assign the SYSOP terminal as the main console. It then returns to DOS and if a. RBBS-PC was invoked via a batch file, and if b. that batch file checks for the batch file which RBBS-PC dynamically builds for SYSOP function 7, and if c. the batch file that invokes RBBS-PC executes the batch file that RBBS-PC dynamically builds for SYSOP function 7, the SYSOP will then see the DOS prompt at the remote terminal and can execute whatever DOS commands or programs the CTTY command support. DOS will look for COMMAND.COM to be present on the disk drive you specified in parameter 105. SYSOP function 7, unlike "doors," loads in a copy of COMMAND.COM to run under the copy that was running RBBS-PC. Also be sure to read Appendix W and make sure that you THOROUGHLY understands the limitations that DOS places on you when this option is invoked. Two areas of caution are advised when using SYSOP function 7 under DOS 2.0 or above. First, each SYSOP should test what can be done remotely. Software that reads and writes directly to the video BIOS and does other things that bypass the standard input and output of DOS simply won't function correctly. Second, you should be aware that you are in DOS and can return to RBBS-PC only by issuing the EXIT command. This will return to the batch file that was built dynamically by RBBS-PC. This file will then continue executing and is designed to reassign the keyboard as the console and then re-invoke RBBS-PC. If you get disconnected while in DOS, your system will be locked up. The console will be assigned to your communication port and your Hayes modem will have dropped the line and will have been set not to auto-answer. The only way to re-boot the system is a manual power off/on sequence. RBBS-PC CPC17-2A Page 194 17.2 SYSOP Use of Function Keys and Numeric Pad ----------------------------------------------- The following function keys (ten keys on the left side of a standard IBM keyboard) are designed to give the SYSOP special local controls that can be actuated without entering the SYSOP mode (using the ESC entry key). The current status of the function keys F3, F4, F6 and F7 are displayed on line 25. F1 - Return to DOS. This will terminate a session if a caller is on- line. In a MultiLink environment when running RBBS-PC out of .BAT file that re-invokes itself it is difficult for a SYSOP to get out of RBBS-PC and exit to DOS locally using F1. To help, RBBS-PC now creates a special file on the same location as the CALLERS file called RBBSxF1.DEF (where "x" is the node ID -- RBBS6F1.DEF for node six). The .BAT file that would otherwise just re-invoke itself, can now check for the existence of this file and if it finds it simply terminate itself. F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the user (if any) remains on-line and the local SYSOP is in DOS until the EXIT command is issued (returning to within RBBS-PC just prior to having pressed the F2 key). The users session is not terminated -- only suspended. F3 - Printer toggle on/off. This changes the printer on-line status. When on-line the printer will print each caller's name and the file names uploaded/downloaded. It will also print all error messages except the ERROR 68 used to check that a file exists. This function should match the condition of the printer. If the printer is going to be left off, the PRINTER toggle should be set to off. When the printer toggle is on, "LPT" will be displayed in positions 8-11 of line 25. F4 - Operator page toggle. This changes the status of "operator annoy" (i.e. allows the SYSOP to be pageable) and records the change in the "node" record associated with the copy of RBBS-PC associated with function key 4. This is set by the CONFIG program parameter 7 which establishes the SYSOP's office hours. This can be used to override and extend the "office hours" set up by CONFIG.BAS. When the "operator annoy" toggle is on, "ANY" will be displayed in positions 5-7 of line 25. F5 - Forces RBBS-PC to tell the modem to answer the phone. F6- SYSOP available. This changes the status of operator available and records the change in the "node" record associated with the copy of RBBS-PC associated with function key 6. This is useful if during your "office hours" you temporarily don't wish to be disturbed. When the SYSOP available toggle is on, "AVL" will be displayed in positions 1-3 of line 25. F7- SYSOP gets control of the system after current user logs off. When the "SYSOP next" toggle is on, "SYS" will be displayed in positions 13-15 of line 25. F8 - Allows the SYSOP to grant an on-line user temporary SYSOP privileges. This is a toggle on/off switch. F9 - SNOOP toggle. This changes the SNOOP from the default value the first time it is pressed and toggles it on/off thereafter. "SNOOP off" clears the screen and turns the cursor off. It also keeps the download beeps from sounding. The SNOOP should be left off for normal use to keep the system startup screen from "burning into" the monitor. If the SNOOP is left on, the monitor should be physically turned off except when you are observing RBBS-PC in action. Leaving the monitor off will not affect performance of RBBS-PC CPC17-2A Page 195 RBBS-PC. F10- This is the forced chat switch. It announces your forced chat and who you are before turning the keyboard over to you and the caller. The ESC key is used to exit Forced chat mode or to answer an "O>perator page" request. The F10 key will not function until a user logging on has reached the Main Menu. END- Logs off and locks out the current user that is on and informs the user that their presence is unacceptable. PgUp - Displays all the information on a current user. This display is kept in the video page 1 (of the 0-7 pages). The user activity is always written to page 0 when SNOOP is active. The user sees no interruption when this occurs as his activity continues unaffected. If you have a monochrome display there is no video pages 1 through 7 only page 0. This will display on the monochrome screen the user information. PgDn - Return to displaying video page 0 (i.e. the page that the users activity is written to when SNOOP is on). LEFT ARROW - Subtracts one minute to the user's current session time. Ctrl/Left Arrow subtracts five minutes to the user's current session time. RIGHT ARROW-Adds one minute from the user's current session time. Ctrl/Right Arrow adds five minutes to the user's current session time. UP ARROW-The keyboard "up arrow" key (i.e. one that generates the character with ASCII value 24 and which is the "8" key on the standard IBM keyboard's numeric pad that is at the right of the keyboard) allows the local SYSOP to increment an on-line users security level by one each time that it is pressed. Control-up-arrow will increase the security in increments of 5. DOWN ARROW -The keyboard "down arrow" key (i.e. one that generates the character with ASCII value 25 and which is the "2" key on the standard IBM keyboard's numeric pad that is at the right of the keyboard) allows the local SYSOP to decrement an on-line users security level by one each time that it is pressed. Control-down-arrow will decrease the security in increments of 5. Some keyboards do not recognize the Control-Up or Control-Down. To accommodate this, the Control-PgUP and Control-PgDn can be used instead. The SYSOP can also enter commands on the command prompt line while a caller is on-line. The command entered will cause the system to respond just as it would if the caller had entered the command. This should be used with caution because it could confuse a new system user -- users are often timid enough without knowing that big brother is actually watching them! Let callers page you and then tell them that you can assist with commands if the get into trouble. RBBS-PC CPC17-2A Page 196 18. MESSAGE AREAS WITHIN RBBS-PC --------------------------------- RBBS-PC is intended to be an open system. As such it can have an unlimited number of message areas and messages. At the very minimum, RBBS-PC has a single 1.) message area, a file named MESSAGES, 2.) user file, a file named USERS, and 3.) definition file, a file named RBBS-PC.DEF In addition to this, additional messages areas can be created as either "conferences" (i.e. areas that use the same RBBS-PC.DEF file as the main RBBS-PC message area) or "sub-boards" (i.e. areas that have their own .DEF file). 18.1 "Conferences" and "Sub-boards" -- the Differences ------------------------------------------------------ A "conference" or "sub-board" can be: 1.) "public" -- any caller can join. 2.) "public with a separate user file" -- any caller can join and RBBS-PC remembers the last message read by each caller. 3.) "semi-public" -- only callers with specific security levels equal to or greater than that specified for the conference can join. 4.) "semi-public with a separate user file" -- only callers with specific security levels equal to or greater than that specified for the conference can join and RBBS-PC remembers the last message read by each caller. 5.) "private with a separate user file" -- only callers who have been pre-registered in the separate user file for the conference can join and RBBS-PC remembers the last message read by each caller. A "sub-board" is just a conference that also has a configuration definition file (.DEF). Sub-boards can be public, private, or semi-private. Access to a sub-board is controlled by the configuration parameter 123 which sets the minimum security level required to enter the "sub-board." A "sub- board" configuration file has the same format as the RBBS-PC main configuration file, and is created and edited using CONFIG.EXE. This allows a "sub-board" to have its own unique welcome file, commands, security levels, menus, help, bulletins, directories, and up and download areas. "Sub-boards" can share as much or as little as desired with other conferences or other "sub-boards" within the same RBBS-PC system. The only things a "sub-board" cannot change are the primary MESSAGES file and the communications parameters used by the RBBS-PC it is running under. RBBS-PC CPC17-2A Page 197 To the caller, a "sub-board" appears just like another bulletin board, accessed from a bulletin board rather than through a telephone number. Public sub-boards, just like public boards, are those whose minimum security to join is not higher than the default security for new users. "Sub-boards" basically allow a single telephone number to offer very different types and levels of services. Independent "sub-boards" run under the same RBBS-PC service radically different types of terminals/PC's. Within the same RBBS-PC, one "sub-board" may have 80 column menus for IBM and compatible PC callers, another may have 40 column menus for Atari and Commodore PC users, and still another may have 20 column menus for those using telecommunications devices for the deaf (TDD's). No longer is it necessary to provide three independent telephone numbers for three such different services. All callers can dial the same number and simply switch over to the appropriate board. Extra lines can be added to a roll-over and service all the boards. "Sub-boards" make it much easier and feasible for a SYSOP to market bulletin board services by allowing hardware to resources to be pooled under one software "umbrella" such as RBBS-PC and yet service a very diverse set of requirements -- much the same way that Compuserve does. One of the best hardware configurations for running a multi-board service like this is PC-Slaves, because adding additional boards are extremely easy, with virtually no system degradation. "Sub-boards" greatly benefit "umbrella" organizations. For example, a computer club that covers IBM computers, Apple, Atari, and Commodore. No longer does software intended for one type of computer have to get mixed in with listings for another computer. Each computer can have not only separate messages, but bulletins and directories as well. "Sub-boards" make it easy to have different "levels" of service based on security level. Many SYSOPs run both a "free" and a "subscription" board. The most typical arrangement for this is to have the free board be on the bottom of a telephone roll-over and the pay board be on the top, and for the top board to require a higher security level. Non-subscribers who call the pay board number get "kicked" off the board. "Sub-boards" on the same telephone line would give both paying and non-paying callers equal access, if desired. Another example is that callers with enhanced security can join a sub-board to get access to even more downloads. Or, executive officers for an organization can have access to a "sub-board" that has not only special messages but special bulletins and files. The naming conventions of the files associated with a "conference" or "sub- board", for example called CLONES, would be: CLONESM.DEF --- the message file CLONESU.DEF --- the user file CLONESW.DEF --- the "welcome" file (for conferences only) CLONESC.DEF --- the configuration file (for "sub-boards" only) Using the configuration .DEF file associated with a "sub-board" allows each SYSOP to make the "sub-boards" as unique or similar as desired. Two security levels are very important. The minimum security to log on to the board determines who can join the "sub-board". And the default security level is what newly added callers are assigned. A "sub-board", like any conference (public, semi-private, or private) is closed to all who have insufficient security. To make a "sub-board" completely private, simply set the minimum CONFIG parameter 123 (the minimum security level a new user needs to logon) to be higher than any normal caller would have. The only way for callers to be able to join a completely RBBS-PC CPC17-2A Page 198 private "sub-board", like a private conference is for the SYSOP to have added them previously to the users file associated with that "sub- board". The security level a caller gets when auto-added is the default security level for the "sub-board" and not the current security level of the caller. This is to prevent special privileges that a caller has in one "sub-board" from automatically propagating into other "sub-boards". For example, a caller with SYSOP privileges in one "sub-board" who joins another does not become receive SYSOP privileges in the other. The security level used to determine what "sub-boards" a caller can join is not the current security level but the original security level the caller had on the main board. RBBS-PC detects if the bulletins in the "sub-board" are the same as in the main RBBS-PC system and does not re-display them when a "sub-board" is joined. "Sub-boards", public conferences, semi-private conferences, and private conferences can all co-exist within the same RBBS-PC system. Sub-boards in turn can have sub-boards in them, as well as public, semi-private, and private conferences. The primary disadvantage of "conferences" or "sub-boards" that have separate user files associated with them is the additional disk space that is required for the users file. RBBS-PC's CONFIG parameter 290 allows the SYSOP to let a user on as a "guest" if there is no more room left in the users file for the "sub-board", semi-private conference, or private conference. Not having a user record defeats one of the main mechanisms for remembering a user's preferences, of course, but the SYSOP can start with a smaller users file and expand later without the risk of denying callers access. Obviously, "sub-boards" take more time to set up and maintain. While it is nice to be able to have parts of RBBS-PC vary radically from one another, every one that does vary is another item to create and maintain. "Sub- boards" can multiply the work necessary, for example, to maintain bulletins. There are more users and message files to oversee. However, Kim Wells MU-EDIT is an invaluable tool for managing multiple message and user files. Give Kim's RBBS-PC call at (703) 350-1299 and get a copy of MU-EDIT. RBBS-PC CPC17-2A Page 199 18.2 Making a "Conference" or "Sub-board" Successful ------------------------------------------------------ To make a "conference" or "sub-board" successful several guidelines should be followed rather rigorously: 1. Establish a "conference" or "sub-board" chairman (i.e. a SYSOP) to manage the conference. The SYSOP's job is to add new users, delete old ones, make sure that the subject and/or the agenda of the conference is adhered to by killing messages that are inappropriate. This is best accomplished by having a separate user file for each "conference" or "sub-board" in which the caller only has SYSOP privileges when in the specific "conference" or "sub-board." 2. Establish an "agenda" or list of subject areas for the "conference" or "sub-board." One of these should be about new subject areas. These areas should be VERY narrow in scope. The essence of any good conference is keeping it focused. Everyone has been in at least one meeting/conference that was a waste of time because whoever was running the meeting/conference did not keep the dialogue centered on the subject or agenda. 3. If a continuity of dialogue is to be achieved, it is advisable to keep the conference "focused" -- either by keeping the number of conference members limited to thirty persons or less or by keeping the subject matter very narrow (i.e. the IBM PC's 30MB disk size limitation). Another interesting thing about "private" conferences and sub-boards as implemented within RBBS-PC is that they are not "public" and, therefore, are even more protected by the first, fourth, and fifth amendments. RBBS-PC CPC17-2A Page 200 18.3 Setting Up a "Conference" or "Sub-board" --------------------------------------------- The SYSOP sets up a "conference" using the CONFIG utility parameter 167 to pre-format up to two files -- one for the messages to be associated with the conference and one for the users to be associated with a conference. The file name for a "conference" can be any seven characters that are valid for a file name. The eighth character must be a "M" (for the messages file associated the conference) or a "U" (for the users file associated with the conference). The SYSOP can then enter the conference member's names in the conference USERS file by using the SYSOP function 5. The SYSOP can "join" any conference and need not be in any particular conference's USERS file. Like "conferences", RBBS-PC supports an unlimited number of "sub-boards". "Sub-boards" are equally easy to create. If CLONES where the name of a public conference (the CLONES message file CLONESM.DEF exists), all that would have to be done to make CLONES a "sub-board" would be to run CONFIG to 1.) create a separate user's file, CLONESU.DEF, for this formerly public conference (if didn't already have a users file), 2.) create a "sub-board" configuration file for the CLONES "sub-board" (a file whose name would be ATARIC.DEF). The easiest way to make a "sub-board" configuration file is to use the DOS copy command, starting with another configuration file as a model (e.g. the one for the main board). To continue with the CLONES example you would issue the DOS command: COPY RBBS-PC.DEF CLONESC.DEF Then invoke CONFIG.EXE to edit that file, using the form CONFIG CLONESC.DEF WARNING!! When you create a .DEF file by copying another one as a model, be sure to run CONFIG against this new file and change the message and user file names! Otherwise your sub-board will share the user file with another message base. Here change the message file name to CLONESM.DEF and the user file name to CLONESU.DEF. The users file name can be anything for a "sub-board" but the extension .DEF is a good idea because RBBS-PC's security system will not let any file with that extension be downloaded. Remember, you do not want to allow callers to download any users file! You get an extra layer of protection if you put the message, user, and configuration files in an area not available for downloading. RBBS-PC CPC17-2A Page 201 18.4 Establishing a "Conference" or "Sub-board" SYSOP ----------------------------------------------------- RBBS-PC has more of the more flexible and powerful systems for supporting "assistant sysops" or "conference moderators". A moderator need not be made a full sysop, and whatever security a moderator has, does not transfer to the rest of the board. Moderators need two basic functions: 1. read and kill all messages, and 2. add and modify users. The ability to do user edits is controlled by the security specified by sysop function 5. Incidentally, moderators cannot edit user records with security higher than theirs. The ability to read and kill all messages is controlled by a security level specified in CONFIG. RBBS-PC supports having separate user files for every message area, so that moderator privileges in one area do not necessarily transfer to others. To set up a conference or sub-board moderator, the SYSOP need only 1. "Join" the conference or sub-board, 2. Use SYSOP function 5 to enter the name of the user who is to be the conference chairperson into the conference's USERS file. 3. Set that users security level in the conference's USERS file to a security level that can issue the SYSOP function 5. This will allow the conference chairman to add users. 4. Set the minimum security to read and kill all messages to the level of the moderator. Any registered user can join a "public" conference or sub-board. When someone issues the J>oin command to join a conference or sub-board, their standard security level is temporarily superseded by the security level associated with their user name within that conference's or sub-board's USERS file if it is a "private" conference. For example, a normal user might be given the security required to add users to a particular conference or sub-board USERS file since they are the SYSOP of that message area. When a user joins the conference or sub-board of which they are chairman, their normal security is bumped up so that they can add users to the USERS file of that particular message area. When the same user exits that message area, their security level is returned to normal. If they should subsequently join another message area where they are not chairman, they would be unable to add users to that message area's USERS file. Other than a message area's SYSOP, none of the message area members should be given any higher security than they otherwise enjoy as a regular RBBS-PC user. RBBS-PC CPC17-2A Page 202 19. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING --------------------------------------------------- RBBS-PC has the ability to notify callers about mail waiting for them when they log on. Callers can be notified for any pair of user/message files (a) how many new messages were left, and (b) whether any new messages are to them personally. RBBS-PC can be configured such that the messages individually reported by number to the caller when the caller logs on are: all messages (i.e. both old and new, or just new messages since the caller last logged on, or no messages at all via CONFIG parameter 19. Of course, RBBS-PC allows the SYSOP to determine if callers are reminded of the mail they have left. In a file specified in CONFIG parameter 93 (the default is CONFMAIL.DEF), the SYSOP can list the message/user file combinations to check for mail waiting in the format <user file>,<message file> where these are related conference file names. If it is assumed that RBBS- PC is running in a DOS subdirectory off of the main root directory of the "C:" drive and that there are two conferences, RBBS-PC and BETA, then an example of the contents of the CONFMAIL.DEF file is: C:\RBBS\BETAU.DEF,C:\RBBS\BETAM.DEF C:\RBBS\RBBS-PCU.DEF,C:\RBBS\RBBS-PCM.DEF The names are processed exactly as typed, so inclusion of the drive/path is necessary. The SYSOP controls what conferences get checked for mail by listing these file pairs. Conferences not listed will not be checked. Callers will get a report only for conferences that they are a member of. Two items of information are reported: number of new messages since last in the conference, and whether any new messages are address to the caller. The name used in RBBS-PC for the main message base is taken from the file name for the message base. As with conferences - if the prefix of if the user file ends with "M", the name will be the composed of all but the last character. If the name is "MESSAGES", it will be called "MAIN". Otherwise the main message base will be called the full prefix. The main message base and users file can be included in the list to scan. You may want to coordinate the USERS and MESSAGES file names in the same fashion that conference user files and message file names are coordinated. If the main message base is to be known as TOP then call it TOPM.DEF and call the users TOPU.DEF. RBBS-PC will work as before with the default names USERS and MESSAGES and call the main message base MAIN, but you cannot include the main message base in the list of message bases to scan for new mail. This is because the new mail scan keys off the user file name, whereas the name of the main message base keys off of the message file name. This constraint can be bypassed by naming the main message file MAINM.DEF and it's corresponding user file MAINU.DEF. However, a good reason to name the main message base something else is so that MAIN does not name both the main command section and the main message base. RBBS-PC CPC17-2A Page 203 There are 3 philosophies that can be implemented on message reporting using the CONFIG parameter 19: 1. Report everything. 2. Make a fast minimal report. 3. Make an optimum intermediate report. Reporting everything means reminding callers of messages they left, and give the messages numbers of old and new mail. To do this it is necessary to set configuration parameters to remind callers of old mail and to report ALL messages to caller. Also place "sub-boards" and private conferences in the mail scan list of CONFMAIL.DEF. Making a fast minimal report means that callers will not be reminded of old messages, specific message numbers will not be list, only the number of new messages and whether any are personal will be reported. This option is for when you want people to get the caller to the command level as fast as possible. For example, the main message base is not even used. To do this set configuration parameters to NOT remind callers of old mail and to report NO messages to caller. Put the main message base as well as "sub- boards" and private conferences in the mail scan list of CONFMAIL.DEF. Providing an optimum intermediate report means reporting individual message numbers only for the new mail as well as # of new messages (and whether any personal). The best way to implement this is to set the level of reporting messages to the caller to New Only and to put all "sub-boards" and private conferences in the mail scan list of CONFMAIL.DEF. Set CONFIG parameter 21 to NOT remind callers of old mail. RBBS-PC CPC17-2A Page 204 20. RBBS-PC QUESTIONNAIRE FACILITIES ------------------------------------- RBBS-PC provides a highly sophisticated script-driven capability that allows a SYSOP to ask new users questions or questions of users when they say G>oodbye. To ask new users questions the file named in CONFIG parameter 84 must exist. To ask questions of users when they say G>oodbye the file named in CONFIG parameter 85 must exist. The SYSOP can set up the script in such a way as to raise or lower a new users security level based on the answers. Contained within the script is the file to which the answers are to be written. RBBS-PC will only activate the corresponding script files if they exist, otherwise the functions are bypassed. The script files should be created with your favorite editor. During the testing phases both EDLIN and WordStar were used and both worked correctly. All "script" files are formatted the same and contain support for: o Branch to labels o Display lines o Display line and get response o Response validation (Multiple choice) o Numeric validation o Forward and backward branching o Raising and lowering user security level o Aborting the questionnaire o Chaining to another questionnaire o Invoke a macro from within a questionnaire o "Turbo" key can be turned on from within a questionnaire The first line in every script file must contain the file name where the responses to the script will be appended as the first parameter and the maximum security level a users security level can be raised to as the second parameter. This file can be any valid text type file. The rest of each script file must contain valid script commands. Script commands are 1 character in length and must be in column 1 of each script line. Following is a list and description of valid script commands: : A colon indicates a label command * An asterisk indicates a display data command ? A question mark indicates a display and wait for response command = An equal sign indicates a multiple choice branch command > A greater than symbol indicates a goto command + A plus sign indicates a raise security level command - A minus sign indicates a lower security level command @ An "at" sign means to abort questionnaire and do not write results & An ampersand means to establish a questionnaire chain T The letter "T" turns on the "turbo" key mode M The letter "M" executes a "macro" > Assigns a value to a work variable CONFIG parameter 94 controls the maximum number of work variables that can be handled by questionnaires. RBBS-PC sophisticated questionnaires even support "graphics" versions of the questionnaires. Graphics versions use the standard convention of ending the file prefix with "C" for color graphics and "G" for ansi graphics. E.g. HLPRBBSC.DEF and HLPRBBSG.DEF are graphics versions of HLPRBBS.DEF. RBBS-PC CPC17-2A Page 205 20.1 Branching to Labels ------------------------ : Colon (Label command) This command is used to provide labels that can be branched to from = and > commands. :QUESTION1 Numeric labels are not recommended because they are easy to confuse with work variables. SmartText variables will be interpreted as such, eg. ":-{FN" will substitute the first name. SmartText and Work Variables are dynamically substituted into all questionnaire lines. For example, >-.[8].- will substitute the value of work variable 8 for "[8]", so that if 8 has "edit" as its value, it will go to the label "-.edit.-". The ability to get and substitute values, and to have graphics versions, means that questionnaires can support many of the features of full screen editing, including transmitting a template, then overlaying values into the template. An example that shows the power of questionnaires is ?29Change what field (1,2,...20) ?[29]Change field [29]. from [[29]] to This asks which field to change and stores answer in work variable 29 (i.e. value of work variable 29 is "7"). The second question then stores the answer in the value of work variable 29, displays the name of the work field being changed, and then displays the old value of the work variable. Suppose that the value of work variable 7 is "Yes". Then the series of substitutions RBBS-PC makes into the second line before executing it are: ?7Change field [29]. from [[29]] to ?7Change field 7. from [[29]] to ?7Change field 7. from [7] to ?7Change field 7. from Yes to RBBS-PC CPC17-2A Page 206 20.2 Display Data Command ------------------------- * Asterisk (Display data command) This command is used to send data to the user. An line to send the text "In order to better......., I would" would look like *In order to better serve those who pass this way, I would "*/FL" will no longer display the "/FL" because it is interpreted as a macro command (see section 8.8). If you want to work variables to overlay a display template, keeping it's length (e.g. for columnar display), put "/FL" after the "*". E.g. if variable 1 has value "12345" and 2 has "abcdef", then */FL.[1]....[2]...... will display ".12345..abcdef...", whereas *.[1]....[2]...... will display ".12345....abcdef......". One of the more useful capabilities of macros that questionnaires can make use of is the ability to append data to any work file, where work variables are merged into a form. This allows the questionnaire data to be saved in virtually any format desired. The other extremely useful macro capability that questionnaires can utilize is the ability to retrieve data from a file into a form, in effect adding a data based file retrieval capability. 20.3 Display Data And Get Response ---------------------------------- ? Question mark (Display data and get response) This command is used to send data to the user and wait for a response. The user will be required to input a response. The ENTER key alone is an invalid response. No other checks are made. YOU OWN YOUR OWN PC? (Y/N) The prompt command accepts an optional number which is interpreted as the number of the Work Variable to store the answer in. For example, " ?8Enter Dept will store the answer not only in the regular way for a questionnaire but also in work variable 8. RBBS-PC CPC17-2A Page 207 20.4 Multiple Choice Response ----------------------------- = Equal sign (Response validation - Multiple choice) This command is used in conjunction with the ? command and must immediately follow the ? command for which it applies. This command allows for checking/editing of single character responses to the preceding ? command and allows branch logic to be exercised based on the response given. Multiple = commands must be coded on the same line. The format follows: =AXXXXXXXXX=BYYYYYYYYY= ZZZZZZZZZZ = Indicates that a single character comparison value follows A Is the comparison value X Is the label to branch to if the response is "A" = Indicates that a single character comparison value follows B Is the comparison value Y Is the label to branch to if the response is "B" = Indicates that a single character comparison value follows (SPACE) This is a special comparison value that is always used as the last comparison value and means "INVALID" response given Z Is the label to branch to if an invalid response is given Maximum line length is 255 characters and the last = on the line "MUST" have a comparison value of " " (SPACE). :QUESTION1 ?Do you run a BBS system. (Y/N) =YQUESTION2=NQUESTION2= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 There is an additional format for the = command, where the comparison value of # (Pound sign) is used. This is used as a numeric check and encompasses 0-9, (), - and space. This format requires two entries. The first is to test for numerics and the second is the invalid response branch label (e.g. "=#QUESTION3= QUESTION2E"). 20.5 Forward And Backward Branching ----------------------------------- > Greater than sign (Forward and backward branching) This command is used to branch to specific labels within the script file. >QUESTION4 RBBS-PC CPC17-2A Page 208 20.6 Raise/Lower User's Security Level -------------------------------- + Plus sign (Raise user security level) This command will add the value in columns 2-6 to the default security level given new users or the current security level of old users. +5 - Minus sign (Lower user security level) This command will subtract the value in columns 2-6 to the default security given new users or the current security level of old users. -1 20.7 Abort Questionnaire ------------------------ @ At sign (Abort questionnaire) This command will terminate the questionnaire and NOT write the response to the output file as in the following example. :QUESTION1 ?Have you answered the questionnaire before. (Y/N) =YQUESTION2=NQUESTION3= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 @ :QUESTION3 20.8 Chain Questionnaire ------------------------ & Ampersand (Chain questionnaire) This command will establish the next questionnaire in the chain. The file named in columns 2-80 will be used as a continuation to the current questionnaire when the current questionnaire reaches its last line. i.e. &L:\RBBS\QUESCONT.DEF 20.9 Turbo Keys --------------- T Turbo Key This is used to turn on Turbo Key for a prompt where a single keystroke is expected. TurboKey causes the next keystroke to be taken as the answer immediately without having to press Enter, if the caller has TurboKey on. 20.10 Macro Execute -------------------- M Marcro Execute This command is used to execute a specified macro named after the command, e.g. "M C:\RBBS\FIZ.IMC". Control returns to the questionnaire after a macro is executed. One of the most important capabilities macros add to questionnaires is the ability to append data to any file in any format desired. Hence the data in questionnaires can be saved where ever desired in whatever format desired. If a macro saves the data and you do not want the normal output on completion of the questionnaire, just abort the questionnaire at the end. Macros also have the ability to retrieve data from files and then display on the screen. RBBS-PC CPC17-2A Page 209 20.11 Assign Value ------------------- < Marcro Assign This command assigns a value to a work variable. For example, "<2 XT" assigns value "XT" to work variable 2. RBBS-PC CPC17-2A Page 210 21. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS ----------------------------------------------------- RBBS-PC attempts to nurture the maximum amount of diversity and innovation as possible. For this reason the source code has always been distributed. The free exchange of information, on of RBBS-PC's two primary objectives requires that communications occur. With PC's this communications is electronic and electronic communications fosters a multiplicity of "protocols" in which data can be exchanged. A "protocol" for the exchange of files is just a set of cooperative conventions that allow two different computer's software to transfer files between themselves. RBBS-PC supports four "protocols" within its own BASIC source code -- ASCII, Xmodem (checksum), Xmodem (CRC), and Ymodem. These are totally configurable by the SYSOP when setting up RBBS-PC. In addition to these four "protocols" and in order to provide advocates of specific protocols a means of adding their particular flavor of communications protocol to RBBS-PC, a standard interface has been created so that "external" protocols can be installed in RBBS-PC. "External" protocols are simply defined as programs outside of RBBS-PC which perform the file transfer. Before calling "external" protocol drivers, RBBS-PC will do the following: 1. verify that the file exists if the file is to be downloaded. 2. for uploads, verify that the file name requested is valid. 3. pass the communications port to the vendor's protocol- handling routine with carrier detect on. RBBS-PC will call the external protocol drivers either via the SHELL command in BASIC or via a .BAT file. RBBS-PC CPC17-2A Page 211 21.1 Parameters passed to a protocol driver -------------------------------------------- RBBS-PC detects the installation of external file transfer protocols via an optional RBBS-PC system file whose default name is PROTO.DEF. If no such file exists, all and only internal protocols will be available -- Ascii, Xmodem, XmodemCRC, Ymodem. This file may be used to rename or delete some or all of RBBS-PC's internal protocols. If a PROTO.DEF file exists, all of RBBS-PC's internal protocols must be specified in it as well. Internal protocols are NOT automatically included when a PROTO.DEF file exists! The protocol definition file has thirteen (13) parameters passed for each external protocols defined for RBBS-PC. Each parameter can be on a separate line of its own or all parameters can be on a single line (separated by commas). The parameters passed for each protocol specified are: Parameter Description 1 Protocol Name 2 Security Level required to use protocol 3 Method to invoke protocol 4 Whether 8 bit connection required 5 Whether "reliable" connection required 6 Whether "batch" mode supported 7 Number of bytes in a block transferred 8 Indicate transfer always successful 9 Factor to estimate file transfer time 10 RBBS-PC "macro" to invoke before protocol 11 Method for checking transfer's success 12 Template to use for downloading 13 Template to use for uploading Protocol Name -- The FIRST CHARACTER is the letter by which a caller selects the protocol. The prompt for the selection of protocol includes the protocol name. It is recommended that the second character be ")" to resemble the rest of the prompts in RBBS-PC, e.g. "Z)modem". RBBS-PC defaults to putting each protocol on the same line, separated by a comma, until the line gets too long. Each SYSOP can control the placement of the line by putting a carriage return line feed at the end of the protocol name. If this is done, the entire protocol name must be in parentheses. For example, instead of the prompt A)scii,X)modem,C)rcXmodem,Y)modem,N)one a SYSOP may want the prompt to be A)scii (text files only) X)modem checksum C)rc Xmodem Y)modem (1K Xmodem) N - None (cancel) RBBS-PC CPC17-2A Page 212 Then the protocol definition file , PROTO.DEF, should be constructed using quotes (to include the carriage return/line feed in the first parameter) as follows: "A)scii (text files only) ",... "X)modem checksum ",... "C)rc Xmodem ",... "Y)modem (1K Xmodem) ",... "N - None (cancel) ",... with the remaining 12 parameters put where "..." occurs. Security Level -- This is the minimum security to be able to use the protocol being described. Method to Invoke Protocol -- A protocol can be invoked by one of three methods: shell, door, or internal (S, D, or I). If "I" is specified, it must be immediately followed by a letter specifying what internal protocol to use, where the choices are A, X, C, Y, or N respectively for Ascii, Xmodem, Xmodem CRC, Ymodem, or None (cancel transfer). "IC" would mean to use RBBS-PC's internal Xmodem CRC. If no protocol is specified equivalent to the internal "None", RBBS-PC will add it. If the letter N is used for a transfer protocol, another protocol must be specified that is equivalent to "None". Whether to Require 8 Bit -- By putting "8" in this parameter, the SYSOP is specifying that the protocol requires the caller to be able to send or receive 8 data bits. If 8 data bits is required and the caller is not at 8 bit, RBBS-PC will prompt the caller to change to 8 bit in order to use the protocol. Whether A Reliable Connections Is Required -- By putting "R" in this parameter, the SYSOP is specifying that the protocol will not be shown or made available to the caller unless the connections is reliable (i.e. such as Microcom's MNP protocol that is built into many modems). Whether Support Batch -- By putting "B" in this parameter, the SYSOP is indicating that "batch" file transfers are allowed with the protocol. "Batch" means a multi-file download request will be processed together. The receive function in Qmodem's "batch" Ymodem attempts to write the file being received to the same letter drive and path name as it is stored on the sending PC. Because it is unlikely that the PC running RBBS-PC will have the same disk letters and path names as the callers, it is recommended that QMODEM's "batch" Ymodem not be used for receiving files via "batch" Ymodem (use DSZ's instead). RBBS-PC enters an external protocol only once to do multiple file downloads. RBBS-PC has been tested with such "batch" protocols as Zmodem's DSZ, Megalink, and Sealink. Blocksize -- This parameter indicates the number of bytes in each block transferred. This is only used to inform the caller the number of blocks to expect when downloading. A zero in this parameters will cause RBBS-PC to RBBS-PC CPC17-2A Page 213 report only the number of bytes to expect. For Xmodem or XmodemCRC this value would be 128. For Ymodem this value would be 1024. Indicate Transfers Always Successful -- If there is no way for the protocol to inform RBBS-PC if a transfer was successful, put a "F" in this parameter, which stands for "Fake" a success report. This means that all transfers will be regarded as successful. Zmodem (DSZ) used in a multi-tasking DOS environment (i.e. where there can only be a single environment) and CLINK are examples of protocols that require this to be set. Factor to Estimate File Transfer Time -- This is the decimal number used by RBBS-PC to estimate the elapse time to download a file. The higher the number, the faster the protocol and the lower the time estimate. Standard equivalents in RBBS-PC are: Ascii ......... 0.92 Xmodem ........ 0.78 XmodemCRC ..... 0.78 Kermit ........ 0.78 Ymodem ........ 0.87 Imodem ........ 0.90 YmodemG ....... 0.95 Windowed xmodem 0.78 If no value is specified, a default of 0.87 will be used. RBBS-PC "Macro" to Invoke Before Protocol -- This is the RBBS-PC "macro" (i.e. a series of standard RBBS-PC commands) to invoke before invoking the protocol. It can be used to display special messages, to delay the start of the protocol, or to prompt for special information passed to the protocol. Method for Checking Transfer's Success -- This is required only for external protocols. This parameter indicates how RBBS-PC is to detect a file transfer's failure. The format is "x=y=z" where: x is which parameter tells whether the transfer was successful, y is the string which indicates failure, and z is an optional parameter telling RBBS-PC whether to write out information needed when DOORing to a protocol in advance of the file exchange. For QMXFER.EXE from John Friel and the Forbin Project, this would be "4=F" - meaning the 4th parameter indicates failure if it begins with "F". For Zmodem as implemented in DSZ from Omen Technologies, the proper choice depends on whether SHELLing or DOORing is used. For SHELLing, put in "1=E" to indicate that the first parameter uses "E" to indicate an error has occurred. For DOORing, put in "4=E=A" to indicate that the fourth parameter uses "E" when an error has occurred. The "=A" means that RBBS-PC is to do an advance write of the filename and protocol used. DSZ then appends its error report to the log file. To the file "XFER-" plus node # plus ".DEF" RBBS-PC will write out a line containing "<filename>,,<protocol letter>". Omitting an "=" causes a default to "4=F". The file checked is "XFER-" plus the node number plus the extension "DEF". On node 1 the file checked is "XFER-1.DEF". Template to Use for Downloading -- This is required only for external protocols. It tells RBBS-PC how to invoke a download. See the following section on discussion of "templates". RBBS-PC CPC17-2A Page 214 Template to Use for Uploading -- This is required only for external protocols. It tells RBBS-PC how to invoke an upload. RBBS-PC CPC17-2A Page 215 21.2 Calling external protocols using "templates" -------------------------------------------------- A "template" is used to inform RBBS-PC how to invoke an external protocol. The first word of the template must be the file name (including file extension) of the program to invoke. RBBS-PC will check to make sure that the file exists. If the file does not exists, the protocol will not be made available to the caller. If the file does exists, the protocol will be shown to the caller. RBBS-PC will dynamically substitute values for pre-defined strings inside a "template". Each supported string is enclosed in square brackets. The strings supported include: [n] where n is a positive integer. Substitutes value in the array A$, which can best be viewed as a work array. Macros can store prompted values in specific elements in the array. [FILE] Name of the file (FILE.NAME$) to be transferred. [BAUD] Baud rate. Speed at which the caller dialed RBBS-PC. [PARITY] Parity used by the caller. [PORT] DOS device name for the communications port to be used for the file transfer (COM1,COM2, etc.). [PORT#] Number of the communications port to be used for the file transfer (1,2,3, etc.). [NODE] Number of the RBBS-PC node invoking the file transfer (1,2,3, etc.). [PROTO]. Letter of the protocol for the file transfer. Everything else in a template will be passed intact. If the external file transfer is to be invoked via a SHELL, it is recommended that the external file transfer program be SHELLed to directly. If the external file transfer is to be invoked via a DOOR, it can be either 1.) DOORed to directly using the same template as for SHELLing, or 2.) DOORed to indirectly via a .BAT file with the command parameters passed to it by RBBS-PC. For example, a "door" for QMXFER might have a download template of: "RBBSQM.BAT [FILE] [PORT] [BAUD] [PROTO]" and the file RBBSQM.BAT have the following in it: C:QMXFER.COM -s -f %1 -l %2 -c -b %3 -p %4 DOS substitutes the passed parameters for the variables beginning with the percent sign. .BAT files are needed if additional programs to run before or after the actual file transfer. The following examples should provide some help in understanding how to invoke external protocols: Example #1: RBBS-PC CPC17-2A Page 216 Z)ippy,5,S,8,,,,,0.98,,,"c:\utl\zippy -s [FILE]","c:\utl\zippy -r [FILE]" Can be interpreted to be: used "Z" as invoking letter, put "Z)ippy" in the prompt, the minimum security to use this protocol is 5, the protocol will be invoked via a SHELL command, an 8-bit connection is required, estimate the download time as 0.98 times as fast as normal, use normal RBBS-PC type of report to check for a successful transfer, invoke the protocol for downloads using the following string: "c:\utl\zippy -s [FILE]" and invoke the protocol for uploads using the following string: "c:\utl\zmodem -r [FILE]" where the file name is substituted for "[FILE]" in either case. Example #2: X)modem,5,IX,8,,,128,,0.8,,,, Can be interpreted to be: used "X" as invoking letter, put "X)modem" in the prompt, the minimum security to use this protocol is 5, the protocol is an internal RBBS-PC protocol, an 8-bit connection is required, and estimate the download time as 0.8 times as fast as normal. RBBS-PC CPC17-2A Page 217 21.3 Parameters Returned by a Protocol Driver ---------------------------------------------- All protocol drivers are expected to return information about the file transfer in a file named XFER-xx.DEF where the value for xx is the node ID (1 to 36). If the protocol cannot accommodate this minimal requirement, it can still be used by telling RBBS-PC to indicate file transfers are always successful -- section 21.1, parameter 9. The one item of information RBBS-PC requires to be returned from an external protocol drive is whether or not the file transfer was successful. The failure indicator MUST BE the first character of any specified parameter in the file XFER-xx.DEF. To show that file transfer failures are indicated by the first parameter and the letter "E" in the file XFER-xx.DEF, parameter 11 (as described in section 21.1) would be written as "1=E". To show that file transfer failures are indicated by the fourth parameter and the letter "F", parameter 11 (as described in section 21.1) would be written as "4=F". No other information is required when SHELLing to external file transfer protocols. However, when DOORing to external file transfer protocols the log file for the transfer MUST HAVE the file name as the first parameter. Protocol drivers that do not have the file name as the first parameter can still be used by telling RBBS-PC to write out three parameters (file name, an empty parameter, and the letter of the file transfer protocol) before invoking the external file protocol. This is done by using parameter 11 (as described in section 21.1). As an example, to DOOR to an external file transfer protocol that indicates a file transfer failure by using the letter "F" in the fourth parameter, but which does not return the file name used, parameter 11 (as described in section 21.1) would be written as "4=F=A". The external protocol would then append its own information to the log file. RBBS-PC CPC17-2A Page 218 21.4 The Protocol Drivers Tested With RBBS-PC ---------------------------------------------- RBBS-PC has been tested with the following protocol drivers: CLINK -- From System Enhancement Associates. Supports batch file transfers but requires that transfers always be assumed successful. DSZ -- From Omen Technologies. Supports Ymodem, Ymodem Batch, YmodemG, and Zmodem. YmodemG requires a "reliable" connection. DSZ logs the results of the file transfers to a file specified in the environment variable DSZLOG. Therefore, the AUTOEXEC.BAT file for an RBBS-PC that uses DSZ should specify "SET DSZLOG=XFER-x.DEF" where x is the node number. DSZ seems unable to create a log file whenever a drive or path is specified. If invoking ZMODEM via the DOOR mechanism, use the "=A" option at the end of the success method check so that RBBS-PC will append the information to the DSZ log it needs and DSZ will then append the success report. In a multi-user environment where a different environment variable for each node can not be specified (i.e. all nodes must share the same DSZ log file), specify that a all transfers are always successful for protocols handled via DSZ. MLINK -- MEGALINK protocol supports batch file transfers but requires that transfers always be assumed successful. PC-KERMIT -- from Columbia University. PCKERMIT.EXE is supplied by The Source as a public service and consists of sliding window KERMIT protocol. The development of "windowing" within the KERMIT architecture (i.e. Super KERMIT) was funded by The Source and implemented by Larry Jordan and Jan van der Eijk. Columbia University holds the copyright and maintains the Kermit protocol. Like RBBS-PC, Columbia University allows KERMIT to be passed along to others and "ask only that profit not be your goal, credit be given where it is due, and that new material be sent back to us so that we can maintain a definitive and comprehensive set of KERMIT implementations". PCKERMIT.EXE is not a terminal program. It simply implements the Kermit protocol, including the sliding window extension. It will work with older "Kermit Classic" implementations as well, via automatic negotiation between the two Kermit programs. PCKERMIT.EXE runs as a "one-shot" execution then returns to RBBS-PC. PCKERMIT does not establish a carrier with a remote system. The connection is established by RBBS-PC. File transfers must always be assumed successful. QMXFER -- is supplied by The Forbin Project as a public service and supports five different protocols -- XMODEM (checksum), XMODEM (cyclical redundancy check), YMODEM, YMODEMG, and IMODEM. QMXFER was implemented by John Friel III, author of QMODEM. YMODEM and YMODEMG are protocols designed by Chuck Frosberg. IMODEM is a protocol designed by John Friel. The later two are designed to work when the link between the two modems is "error free" (i.e. both modems have the MNP protocol built in)> QMXFER.COM runs as a "one-shot" execution then returns to RBBS-PC. QMXFER does not establish a carrier with a remote system. The connection is established by RBBS-PC. File transfer failures are RBBS-PC CPC17-2A Page 219 indicated by an "F" in the fourth parameter of the log file returned to RBBS-PC. WXMODEM -- is supplied by The Forbin Project as a public service and supports the window XMODEM protocol designed by Pete Boswell. Like all of RBBS-PC's protocol drivers, WXMODEM.COM runs as a "one-shot" execution then returns to RBBS-PC. WXMODEM does not establish a carrier with a remote system. The connection is established by RBBS- PC. File transfer failures are indicated by an "F" in the fourth parameter of the log file returned to RBBS-PC. Other protocols tested with RBBS-PC include SuperK and Jmodem. RBBS-PC CPC17-2A Page 220 22. UPLOADED FILE TIPS ---------------------- If someone uploads a BASIC file to you, and it will not list on your screen using the DOS TYPE command, you should go into BASIC, load the file, list it, then re-save it using the same name. If when you try to load the file into the BASIC interpreter you get a `Direct Statement In File' error printed on the screen, the BASIC file has a line without a line number. This will not interfere with the re-saving of the file unless the direct statement is at the beginning of the file; if the file lists properly, then the direct statement is at the end of the file. If the file does not list properly, then the direct statement is at the beginning of the file and has to be removed using a text editor (EDLIN) before the program can be loaded and run. Do not attempt to save a BASIC file after getting the `Direct Statement In File' error during loading without listing the program first; you will destroy the file otherwise. If you wish to load an uploaded file (a BASIC program or any other text file) into a text editor to change the content of the file, you will first have to first add line feeds to the end of each line (after each carriage return). Finally, every SYSOP should assume that any uploaded file him that can be executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the files available to the PC it is executed on. This may be because the documentation is in error, the program was executed incorrectly, or the program was designed to be malicious. It behooves every SYSOP to know what every uploaded file does in order to protect not only the RBBS-PC system, but its users. RBBS-PC CPC17-2A Page 221 23. DUE WARNING AND SYSOP'S LEGAL LIABILITY ------------------------------------------- While no definitive case-law or legislation exists defining the liabilities of System Operators, every SYSOP should assume that they are as responsible for their own actions when running an electronic bulletin board system as they would be for any other action as a citizen of the United States who chooses to exercise their right to freedom of speech. One of the unique features of RBBS-PC is that users have to OVERTLY register themselves -- even when the RBBS-PC is "open" to the general public. This gives each SYSOP the opportunity to give every user "due notice" and require each user to actively acknowledge such notice. For some SYSOPs it is simply the rules of their board. For me, the following is what I use as the text in my NEWUSER file: "Welcome to the world of RBBS-PC! Before continuing you should understand your responsibilities as a RBBS-PC user. Specifically they are: 1. Actively encourage and promote the free exchange and discussion of information, ideas and opinions, except when the content would compromise the national security of the United States; violate proprietary rights, personal privacy, or applicable state/federal/local laws and regulations affecting telecommunications; or constitute a crime or libel. 2. Use your real name and fully disclose any personal, financial, or commercial interest when evaluation any specific product or service. 3. Adhere to these rules and notify me immediately when you discover any violations of the rules. 4. All of the mail is readable by the SYSOP and therefore should not be regarded as private. FURTHER every user explicitly acknowledges that all information obtained from this RBBS-PC is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to the implied warranties of merchantability and fitness for a particular purpose and that the entire risk of acting on information obtained from this RBBS-PC, including the entire costs of all necessary remedies, is with those who choose to act on such information and not the operator of this RBBS-PC. Register if you agree." This won't protect you from prosecution if you allow your RBBS-PC to be used for criminal activities. However, it does serve to cause each user to voluntarily and OVERTLY accept my "rules" and allows me to sleep better at night knowing that I have given "due notice." My own personal philosophy is to actively pursue and prosecute ANY user on my board who I find engaging in what appears to be a violation of the above notice. Essentially, if you are going to run an RBBS-PC open to the general public as I do, your board's reputation and standards must be able to withstand public scrutiny. If you don't feel you can maintain such standards, either don't run a RBBS-PC or run a very, very private one (and be sure to put all your assets in the wife's and kid's names). Since I'm not a lawyer, if you want a legal opinion on your liabilities as a SYSOP your only source of legal advice should be an attorney licensed to practice in your state. Just remember it may not be the best advice and that the legal liabilities regarding the operation of bulletin board systems is unclear. RBBS-PC CPC17-2A Page 222 24. COMPILING AND LINKING RBBS-PC --------------------------------- RBBS-PC source code is distributed along with the executable program RBBS- PC.EXE. It is NOT necessary to recompile or re-link RBBS-PC in order to utilize RBBS-PC. However, some users may wish to modify the source and recompile it. This section is intended for those hardy few who choose to do so. Remember only what is distributed is supported -- anything else is strictly yours to debug! RBBS-PC's source code is compilable by the IBM BASIC Compiler Version 2.0 as released by IBM and with the IBM updates to it through 11/22/85. Subsequent patches released by IBM for the Version 2.0 compiler appear to disable the compiler to the point where it can not compile RBBS-PC. RBBS- PC's source code is compilable by all of Microsoft's QuickBASIC Compilers - - versions 1.02, 2.01, 3.0, and 4.5. However Microsoft's QuickBASIC Compiler version 3.0 is the compiler used to generate the .EXE files distributed with RBBS-PC because it appears to be the most reliable. Versions too buggy to use at all include 1.0, 2.0, and 4.0. 24.1 Compiling CONFIG and RBBS-PC --------------------------------- RBBS-PC's .EXE files are distributed after having been compiled with QuickBASIC Version 3.00 compiler that had the DTR patch described in Appendix T applied to it. CONFIG.EXE is generated from compiling with multiple BASIC source files -- CNFG-VAR.BAS, CONFIG.BAS, CNFG-SUB.BAS. The output of the multiple compiles (CONFIG.OBJ and CNFG-SUB.OBJ) generate multiple .OBJ input files to the LINK step that create CONFIG.EXE. The QuickBASIC version 3.0 compiler command should be: QB CONFIG.BAS,/E/O/C:2048/S; QB CNFG-SUB.BAS,/O; The command for IBM BASIC Compiler version 2.00 should be: BASCOM CONFIG.BAS,,NUL,/E/O/C:2048/N BASCOM CNFG-SUB.BAS,,NUL,/O/N Compiling CONFIG requires that CNFG-VAR.BAS be in the sub-directory from which they are being compiled. RBBS-PC.EXE is generated from compiling with multiple BASIC source files -- RBBS-VAR.BAS, RBBS-PC.BAS, RBBSSUB1.BAS, RBBSSUB2.BAS, RBBSSUB3.BAS, RBBSSUB4.BAS, and RBBSSUB5.BAS. The output of the multiple compiles (RBBS-PC.OBJ, RBBSSUB1.OBJ, RBBSSUB2.OBJ, RBBSSUB3.OBJ, RBBSSUB4.OBJ, and RBBSSUB5.OBJ) generate multiple .OBJ input files to the LINK step that, along with some other .OBJ files, create RBBS-PC.EXE. The command for QuickBASIC version 3.00 should be: QB RBBS-PC.BAS,/C:4096/O; QB RBBSSUB1.BAS,/X/O; QB RBBSSUB2.BAS,/O; QB RBBSSUB3.BAS,/O; QB RBBSSUB4.BAS,/O; QB RBBSSUB5.BAS,/O; QB 4.5 can be used to compile RBBS-PC as follows: RBBS-PC CPC17-2A Page 223 BC RBBS-PC.BAS,/C:4096/O/MBF; BC RBBSSUB1.BAS,/X/O/MBF; BC RBBSSUB2.BAS,/O/MBF; BC RBBSSUB3.BAS,/O/MBF; BC RBBSSUB4.BAS,/O/MBF; BC RBBSSUB5.BAS,/O/MBF; The command for the IBM BASIC Compiler version 2.00 should be: BASCOM RBBS-PC.BAS,,NUL,/C:4096/O/N BASCOM RBBSSUB1.BAS,,NUL,/X/O BASCOM RBBSSUB2.BAS,,NUL,/O BASCOM RBBSSUB3.BAS,,NUL,/O BASCOM RBBSSUB4.BAS,,NUL,/O BASCOM RBBSSUB5.BAS,,NUL,/O Compiling RBBS-PC requires that RBBS-VAR.BAS be in the sub-directory from which they are being compiled. For debugging purposes, RBBS-PC.BAS and RBBSSUB2.BAS through RBBSSUB5.BAS can be compiled with the /E option in addition to those shown. The BASIC compiler library routines have a NASTY bug in them for those who would like to allow KERMIT protocol to be used, exit to DOS as a remote SYSOP, or exit to a "door." If you re-compile RBBS-PC and desire to utilize any of these three RBBS-PC functions, YOU MUST patch your compiler's libraries as described in Appendix T.! RBBS-PC CPC17-2A Page 224 24.2 LINKing CONFIG ------------------- CONFIG.OBJ can be LINKed to produce CONFIG.EXE with the command LINK CONFIG+CNFG-SUB+RBBSUTIL+FOSSCOMM+xxxCOM,CONFIG.EXE,,; assuming that all the required files are on the default drive. NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. 24.3 LINKing RBBS-PC -------------------- RBBS-PC.OBJ can be LINKed to produce RBBS-PC.EXE with the LINKer command (all on one line) -- LINK @LINKLST3.DAT, where the file LINKLST3.DAT contains the following: RBBS-PC+ RBBSSUB1+ RBBSSUB2+ RBBSSUB3+ RBBSSUB4+ RBBSSUB5+ xxxCOM+ QBARCV4+ ANSI17+ XMODEM+ RBBSML+ BDRIVEC2+ PC-NET+ 10-NET+ RBBSUTIL+ RBBSDV+ GIVEBK31+ FOSSCOMM+ BASNOV+ RBBSHS, , , BCOM30.LIB /STACK:2048 NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. New with 17.2A are RBBSHS.OBJ, BASNOV.OBJ and QBARCV4.OBJ. For QB4.5, there is no xxxCOM.OBJ and the LIB used in BCOM45. The above LINK command assumes that all the necessary .OBJ files are on the default drive and the necessary .LIB files are on the "C" drive. RBBS-PC CPC17-2A Page 225 25. LIMITED LICENSE ------------------- The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and each user is free to use and share it under the following conditions: 1. You may NOT distribute RBBS-PC in modified form. 2. You may NOT charge a fee for RBBS-PC itself, and 3. You MUST retain all references to the copyright and authors. Please distribute the original version (or update thereof) of the program. If you have changes please distribute them using the conventions described in section 1.4. This is necessary so that future revisions can be easily added to the system without requiring the entire program. Please do NOT resequence the program. All revisions will be as files that replace the base program or update thereof and the existing line numbers will be referenced when describing new fixes and enhancements. RBBS-PC CPC17-2A Page 226 26. LIMITED WARRANTY -------------------- The RBBS-PC program is provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with the user, and should the program prove defective, the user and not the authors will assume the entire cost of all necessary remedies. None of the authors warrant that the functions contained in the program will meet any users' requirements or that the operation of the program will be uninterrupted or error-free. In any case, each author's entire liability will be limited to the total amount of money the individual user paid directly and explicitly to each author for the use of RBBS-PC. RBBS-PC CPC17-2A Page 227 27. UPGRADING TO CPC17-2A ------------------------- When upgrading to CPC17-2A from earlier versions of RBBS-PC, follow the following steps: 1. Do not destroy or overwrite your old files. You may run into difficulties and have to fall back to the old version. Especially keep a backup of your current USERS, MESSAGES, configuration "DEF" files, and your RBBS-PC.EXE and CONFIG.EXE files. 2. Start by trying to get the new version just to run equivalently to the old without implementing new features. Implement new features one at a time. Do not try to implement everything new at once. 3. The file that almost always changes between non-maintenance versions is a configuration "DEF" file. A utility program called RECONFIG.EXE is provided that converts all versions from 14.1D on to the latest. This will save you the trouble of manually re-entering the parameters. If you do not have RECONFIG you should print out all the options you selected on your current RBBSxPC.DEF file. 4. CONFIG.EXE has an option to review the parameters changed since the last version. You should always run this to see what is new and possibly change the values. If you do not have RECONFIG, you generally need to delete your current RBBSxPC.DEF file and manually enter the parameters. Sometimes, however, the same parameters will be in a different place in the new configuration. If you are upgrading from several versions back, there is no simple way of knowing what all is new. 5. The MESSAGES and USERS files are the two that are most important to continue to be able to use. RBBS-PC 17.2A is compatible on both accounts with files at least back through version 14. However, there is a critical parameter to set in CONFIG: the minimum security to auto-add a user to a conference. This applies to conferences not sub-boards, i.e. that have no configuration DEF file. Go into CONFIG, conference mode, and then check this value. No one will be able to join the conference if their security is below this number, even the sysop. Reset this value so that the desired callers can join the conference. 6. RBBS is written to be upward compatible, preserving all the functions of earlier versions. However, you may have to make changes to the new configuration to make it run equivalently. For version 17.2A, the things you especially need to consider are: (a) the minimum security to read and kill all messages. If this is set to 0, everybody can read everyone else's mail! (b) RBBS formerly supported the "arc" format exclusively. Now "zip" is its default, but it can be set up for any. Review the parameters for default extension and archiving command. (c) Your personal directory may not work unless you include a drive/path. Re-enter the parameter value in config. 7. If you are upgrading from a version prior to 17.1x, consider the possibility that the PASSWRDS file may have a different format, that external protocols are controlled by an external table (PROTO.DEF), that the doors interface may be different, and the control for an timed even may be different. Read the pertinent sections in config on this topics if you are using them. RBBS-PC CPC17-2A Page 228 8. Use the new text files, especially the menus and help files. If you have customized versions of these, start with the distributed files and change them. 9. Last, review the documentation on the major areas of enhancements. The major changes in 17.2A are: a. use of shelling triggered by the presence of BAT files to test uploads for integrity, convert uploads to a different format, and support viewing of text files inside ZIP files, and verbose list any compressed format, b. greatly enhanced macros and questionnaires, including new data base functions, c. enhanced doors interface, including an external control file for doors (DOORS.DEF) as well as the ability of a door to request that RBBS change the user record (DOUTx.DEF), pass any information via command line or a file to a door, and for a door to return information to be displayed to the caller d. the message files can be configured to have minimum size to hold the messages and let grow in size as new messages are added, e. conferences and subboards can be configured to automatically change the user's security to match the logon security, f. message quoting, allowing the option to type in be the same on different submenus and be a single keystroke, speech synthesizer support for visually impaired sysops, making uploads immediately shareable on Novell networks, an easy way to give a conference moderator access to all mail without having to make them sysops, chained FMS directories, and more. PLEASE NOTE!!!!! ---- CPC17-2A has a new CONFIG (version 17-2A) that will create a different DEF file than prior versions! RBBS-PC CPC17-2A Page 229 28. PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE --------------------------------------------------- As PC's (IBM's and others) become more common in homes and offices, their use as vehicles for information exchange continues to grow -- as so eminently attested by the astounding growth of RBBS-PC itself! A national meeting of SYSOPs could foster this growth in information exchange; assist in focusing on the issues (regulatory and otherwise) that foster/inhibit this growth; and act as a forum for new ideas. A national meeting, perhaps sponsored by the Capital PC User Group or even a consortium of other not-for-profit PC user groups could be held . SYSOPs are not only in the big corporations but also in the millions of small businesses, non-profit associations, educational institutions in which the RBBS-PC concept has found a home. They are often the decision influencers in their organizations or area -- as U.S. Robotics discovered when they introduced their Courier 2400 baud modem so successfully. As I expect most who would attend would be paying their own way, the first conference would probably consist of that small "band of brothers" who have set up boards out of the intensity of their own commitment. My own vision of such a conference is sort of a 1980's electronic "Woodstock" -- if for no other reason because of the very "volks" nature of SYSOPs. It has been a long time since there has been a conference "of the people, by the people, and for the people." What follows is a hypothetical agenda of what might be of interest at such a conference. The agenda consists of a "technical" and a "non-technical" (management?) set of sessions as follows: "technical sessions" "non-technical sessions" 8:30 - 10:00 RBBS-PC Record Layouts How to Copyright Software -- (CALLERS, USERS, and its protection and penalties MESSAGES files) for violation of copyrights. 10:30 - 12:00 Multi-Port RBBS-PC 1986 Computer Privacy Act and Systems-- actual "computer trespass" laws at experiences. the State level. 12:00 - 1:30 Luncheon with a nationally known guest speaker (any suggestions?) 1:30 - 3:00 RBBS-PC "doors" and Business Applications of "doorware" explained. Bulletin Board Systems 3:30 - 5:00 Modems -- beyond 2400 The use of RBBS-PC in local, baud. State, and Federal agencies. 5:00 - 6:30 CONNECT TIME! -- Vendor Presentations and Receptions If you are with a manufacturer or organization that might be interested in sponsoring such a meeting, work with your organization to make it happen! If in the normal course of your business contacts you see a potential sponsor of such a conference, persuade them to look into being a sponsor. I would be glad to talk with anyone about going forward with this project. If you are interested in participating, write me at the following address: RBBS-PC CPC17-2A Page 230 Tom Mack National SYSOP Conference 39 Cranbury Drive Trumbull, Connecticut 06611 Please indicate 1. Which four sessions you would attend (in order of preference). 2. Any additional sessions you would be interested in. 3. Who would you want as a guest speaker at the luncheon. 4. Where you would like such a conference held from among the following five locations: a.) Boston, Mass. b.) Chicago, Ill. c.) Houston, Texas d.) San Francisco, Calif. e.) Washington, D.C. 5. Your mailing address. 6. Telephone numbers you can be reached at (both voice and data). 7. And if you would be willing to be a "worker" as well as an attendee -- i.e. stuff envelopes, keep the mailing list, make hotel arrangements, etc. My greatest fear is not that there will be fifty of us -- but that there will be 2,000 of us! Whatever happens, it should be fun. RBBS-PC CPC17-2A Page 231 29. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD -------------------------------------------------------- RBBS-PC'S "Userware" concept is founded on the principle stated in section 1 -- "software which is shared becomes better than it was." Relying on Federal copyright protection, it is my firm belief that RBBS-PC's source code can be distributed without the risk of "loss of ownership" (i.e. it becoming "public domain"). In fact I think that all software (commercial and non-commercial) should be distributed as both compiled/executable files and with their source code. With one exception, RBBS-PC's copyrights have never been violated -- this is due more to the fact that RBBS-PC enthusiasts are ever-vigilant of RBBS-PC's copyrights rather than due to any lack of attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting public. Incorporating these new features and ideas into each new release of RBBS- PC, making sure that upward compatibility with earlier version of RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things that I accept the responsibility for. However, it is RBBS-PC's "support staff" (i.e. all those who enhance RBBS-PC and share such enhancements) that continues to make RBBS-PC a unique experiment in PC software. No one should feel that the possibilities for RBBS-PC have even begun to be exhausted. In fact, I am absolutely certain that even as this is written innovative enhancements are being created for RBBS-PC that I haven't even mentioned. It is my sincerest hope that if RBBS-PC continues to succeed within the IBM PC industry in becoming the "bulletin-board standard," software vendors will begin examining the reasons for RBBS-PC's success and come to understand that: 1. The best form of software support is user support; 2. The best source for software enhancements are from it's users; 3. The best software continually adopts itself to users needs; and 4. The best way to minimize software development is to distribute source code; Each RBBS-PC system operator has the opportunity to affect what RBBS-PC becomes in the future. Many already have. RBBS-PC continues to grow and expand because hundreds (and quite possibly thousands) of SYSOPs spend the time and trouble not only to modify RBBS-PC to meet their needs, but also to share these modifications with others. I do not know of any other software for the IBM PC that has such a vast number of programmers supporting it. In section 1.3, I name more than 70 such individuals and acknowledge that there are a lot more! With the structured design RBBS- PC's source code that the new BASIC compilers allowed, even more RBBS-PC system operators are invited to contribute. Take the time! Make the difference! RBBS-PC CPC17-2A Page 232 APPENDIX A -- RBBS-PC Record Formats ------------------------------------ This appendix is intended to document the record formats of some of the more significant records used within RBBS-PC. As such, it is intended more as a "programmers' guide" for those who wish to write RBBS-PC utilities rather than as "user documentation." No record format is "sacrosanct" and any of them may be changed in future releases. However such changes are not made capriciously and, when they are made, are accompanied by some utility program that will allow the old files to be reformatted into the new format. The MESSAGES file contains the messages that have been left on RBBS-PC. It is a random file with 128-byte records. The first record of the MESSAGES file acts as RBBS-PC's "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. Each "node" record represents the activity/options associated with a particular copy of RBBS-PC ("node"). There can be up to thirty-six copies of RBBS-PC running simultaneously sharing the same set of static files. Therefore there can be up to thirty-six "node" records following the "checkpoint" record. The MESSAGES file has the following logical format: +----------------------------------------------+ Record #1 | RBBS-PC "checkpoint" record | +----------------------------------------------+ Record #2 | RBBS-PC "node" record for node # 1 | | | | up to | | | | RBBS-PC "node" record for node # 9 | | RBBS-PC "node" record for node # 0 | | RBBS-PC "node" record for node "A" | | | | up to | | RBBS-PC "node" record for node "Z" | | | +----------------------------------------------+ | First Record in Message portion of file | +----------------------------------------------+ | | \ Message records that have been used \ \ \ | | +----------------------------------------------+ | Record available for next message | +----------------------------------------------+ | Last record available in MESSAGES file | +----------------------------------------------+ RBBS-PC CPC17-2A Page 233 The FIRST RECORD of the "MESSAGES" file acts as a "checkpoint" record for all the multiple RBBS-PC's that may be sharing the MESSAGES and USERS files. It contains information critical to maintaining the integrity of these two files. The layout of RBBS-PC Message File Record Number 1 is as follows: Position Length Description 1 - 8 8 Number assigned to the last message entered 9 - 10 2 Security level required to be auto-added to a conference 11 - 20 10 Current caller number 21 - 56 36 --- RESERVED FOR FUTURE USE ---- 57 - 61 5 Count of the number of USER records used 62 - 67 6 --- RESERVED FOR FUTURE USE ---- 68 - 74 7 Record Number where "messages" portion of the MESSAGES file begins 75 - 81 7 Record Number of the next available record in the MESSAGES file where the next message may be written 82 - 88 7 Record Number of the last record in the MESSAGES file 89 - 95 7 Maximum number of messages allowed in the MESSAGES file 96 -126 31 --- RESERVED FOR FUTURE USE ---- 127 -128 2 Maximum number of RBBS-PC's sharing this MESSAGES file As a programming reference, line numbers 1900 and 23000 of the BASIC source code for RBBS-PC.BAS contains the code for reading this "checkpoint" record. RBBS-PC CPC17-2A Page 234 Following the first record of the MESSAGES file are from one to 36 "node" records. Each "node" record contains information critical to the running of that copy of RBBS-PC associated with that "node". The layout of each RBBS-PC "node" record is as follows: Position Length Description 1 - 31 31 Name of last person on this copy of RBBS-PC 32 - 33 2 SYSOP available indicator (true or false) 34 - 35 2 SYSOP annoy indicator (true or false) 36 - 37 2 SYSOP is to be on next indicator (true or false) 38 - 39 2 Line printer available indicator (true or false) 40 - 41 2 Door's availability indicator (true or false) 42 - 43 2 Eight bit transmission indicator (true or false) 44 - 45 2 Caller's baud rate indicator: -1 = 300 baud -2 = 450 baud -3 = 1200 baud -4 = 2400 baud -5 = 4800 baud -6 = 9600 baud -7 = 19200 baud 46 - 47 2 Upper case only indicator (true or false) 48 - 51 4 Number of bytes transferred (from external protocols) 52 1 Batch transfer indicator (not zero = batch) 53 - 54 2 Graphics indicator (0 = text, 1 = full ASCII, 2 = color) 55 - 56 2 SYSOP indicator (-1 = SYSOP) 57 1 Activity indicator (I=inactive, A=active) 58 - 59 2 SNOOP on indicator (true or false) 60 - 64 5 Baud that RBBS-PC talks to the modem at (single precision) 65 - 67 3 Time user logged onto the system (HH:MM:SS) 68 - 71 4 --- RESERVED FOR FUTURE USE --- 72 - 73 2 Private door indicator (true or false) 74 1 Type of transfer to external program: 0 = none 1 = download a file 2 = upload a file 3 = external registration program 75 1 First letter of file transfer protocol 76 1 --- RESERVED FOR FUTURE USE ---- 77 - 78 2 Last date, MM-DD-YY, that RBBS-PC exited to DOS (packed) 79 - 85 7 --- RESERVED FOR FUTURE USE ---- 86 - 90 5 Last time, HH:MM, that RBBS-PC exited to DOS 91 - 92 2 Reliable mode indicator (true or false) 93 - 116 24 Work area that normally contains caller's City and State, but when temporarily exiting RBBS-PC used as: Position Length Description 93 -100 8 Programmable user interface file name 101 -102 2 Local user indicator (true using local PC) 103 -104 2 Local user mode (true if using COM0) 105 -112 8 Name of current "conference" or "sub-board" 113 -116 4 --- UNUSED ---- 117 -118 2 Subsystem index of last subsystem user was in. 119 -124 6 Month, day, and year, MMDDYY, exited to external protocol 125 -128 4 Hour and minute, HHMM, exited to external protocol As a programming reference and in order to see how these fields are set/used in the node records, review the following line numbers in RBBS- PC.BAS -- 150, 200, 400, 420, 842, and 13555. In addition, review the following subroutines as well: RBBS-PC CPC17-2A Page 235 Source Code Subroutine RBBSSUB2.BAS ---- WHOSON RBBSSUB3.BAS ---- FINDFUNC SAVEPROF READPROF RBBSSUB4.BAS ---- TIMEDOUT A message within the messages file consists of a MESSAGE HEADER followed by the text of the message. The RBBS-PC Message File "message header" record layout is as follows: Position Length Description 1 1 Contains an "*" for read-only messages, blank otherwise 2 - 5 4 Message number of this message 6 - 36 31 The name of the person the message is from 37 - 58 22 The name of the person to whom the message is sent 59 - 66 8 Time of day that the message was sent (HH:MM:SS) 67 - 67 1 ---- RESERVED FOR FUTURE USE ---- 68 - 75 8 Date the message was sent (MM-DD-YY) 76 -100 25 Subject of the message 101 -115 15 Password for the message (if any) 116 -116 1 "Active" message indicator = hex 225 "Killed" message indicator = hex 226 117 -120 4 Number of 128-byte records for this message -- including the the "message header" record. 121 -122 2 Minimum security level to read message 123 -125 3 Date (packed) the message was last read (MM/DD/YY) 126 -128 3 Time (packed) the message was last read (HH:MM:SS) As a programming reference, review lines 3405, 3460, 3530, and 8076 of the BASIC source code for RBBS-PC.BAS to see how these fields are set. Each record following the MESSAGE HEADER record is a MESSAGE TEXT record and consists of 128 characters. Each of these 128-byte message text" records contains the message text. The end of each line in the message is followed by an RBBS-PC "end-of-line" indicator which is equal to an ASCII 227. This allows RBBS-PC to "pack" multiple message lines in a single 128-byte record. RBBS-PC CPC17-2A Page 236 Information unique to each person who logs on is contained in the USERS file (a random file of 128-byte records). Each records is as follows: Position Length Description 1 - 31 31 Users first and last name (separated by a blank). 32 - 46 15 Users password for logon. 47 - 48 2 Users security level (permanent). 49 - 62 14 Users logon options (see detail breakdown below). 63 - 86 24 City and state from which the user is calling. 87 - 89 3 ---- RESERVED FOR FUTURE USE ---- 90 - 93 4 Number of files downloaded today 94 - 97 4 Number of bytes downloaded today 98 -101 4 Number of bytes downloaded (ever). 102 -105 4 Number of bytes uploaded (ever). 106 -119 14 Date and time the user was last on (MM-DD-YY HH:MM). 120 -122 3 Date the user last listed a directory. 123 -124 2 Number of files downloaded (ever). 125 -126 2 Number of files uploaded (ever). 127 -128 2 Elapsed time the user was on for day of last access. Line 9400 of the BASIC source code for RBBS- PC.BAS contains the code for opening this file. The user's logon options, positions 49 through 62, are utilized as follows: Position Length Description 49 - 50 2 Number of times the user has logged on 51 - 52 2 Last message number read by the user 53 1 Protocol Preference (blank if none, otherwise letter) 54 1 Graphics Preference (see meaning below) 55 - 56 2 Margin length for this users messages 57 - 58 2 Bit Flag -- this 16-bit field is denoted by bit 0 being the least significant (i.e. right-most bit) and bit 15 being the most significant (i.e. left-most bit). These "bit flags" have the following meanings (0=off, 1=on): BIT Definition (what ON means) 0 Bell prompts 1 "Expert" mode 2 Nulls 3 Upper case only 4 Line feeds 5 Skip old bulletins 6 Check new files on logon 7 Use autodownload 8 Required questionnaire answered 9 Mail Waiting 10 Highlighting enabled 11 "TurboKey" enabled 12-15 RESERVED FOR FUTURE USE 59 - 60 2 Date subscription began 61 1 Page length to use for this users terminal 62 1 ------- RESERVED FOR FUTURE USE --------- --- 14 The meaning of the graphics preference byte depends on the numeric value it has. The caller can specify, for text files, no graphics, ascii graphics, or ansi color graphics; then the color, and then whether normal or bold. For example, if graphics perference for text files is color, and preference for normal text is light yellow, graphics preference stored is 38. Colors RBBS-PC CPC17-2A Page 237 are Red, Green, Yellow, Blue, Purple, Cyan, and White. normal bold graphics\color R G Y B P C W R G Y B P C W none ...... 30 33 36 39 42 45 48 | 51 54 57 60 63 66 69 ascii ...... 31 34 37 40 43 46 49 | 52 55 58 61 64 67 70 ansi ...... 32 35 38 41 44 47 50 | 53 56 59 62 65 68 71 RBBS-PC CPC17-2A Page 238 APPENDIX B -- RBBS-PC in a DESQview Environment ----------------------------------------------- Before you continue, make certain you have read and thoroughly understand the instruction manual provided with your copy of DESQview. 1. Modifications to DOS CONFIG.SYS and RBBS-PC batch files: ------------------------------------------------------------ The first step in using DESQview with RBBS-PC is setting up your CONFIG.SYS file. Files=25 is probably the most critical value. This value tells DOS how many files may be open at the same time. This value may need to be increased if you intend to run more than 2 nodes of RBBS-PC. A typical CONFIG.SYS file should include the following: files=25 buffers=25 (device=ansi.sys is not required when using DESQview) If you intend to use two or more nodes of RBBS-PC, a batch file will be required for each node. These batch files will eventually be executed from the DESQview "Open Window" menu and will load each node of RBBS-PC. Contents of RBBS1.BAT Contents of RBBS2.BAT if exist rctty1.bat del rctty1.bat if exist rctty2.bat del rctty2.bat watchdg1 off watchdg2 off rbbs-pc.exe 1 rbbs-pc.exe 2 watchdg1 on watchdg2 on if exist rctty1.bat rctty1.bat if exist rctty2.bat rctty2.bat rbbs1.bat rbbs2.bat In the above examples, the program WATCHDOG is being used to monitor for carrier when the SYSOP has dropped into DOS remotely or a user has opened a Door. For example, WATCHDG1 monitors COM1 and WATCHDG2 monitors COM2. If you aren't using WATCHDOG, leave these commands out of your batch files. 2. What to Tell RBBS-PC's "CONFIG" Utility ------------------------------------------ When using DESQview you will need to change CONFIG parameter 162 that you are running under DESQview. 3. Running Multiple Nodes (or copies) of RBBS-PC ------------------------------------------------ If you intend to use two or more nodes of RBBS-PC, you will need to change a few additional parameters with the RBBS-PC "CONFIG" utility. When using multiple nodes of RBBS-PC you will be using a .DEF file for each node. Each node will have a .DEF file named RBBS?PC.DEF where ? represents the number of the node. These are created by answering YES to the question "Will you be running multiple copies of RBBS-PC (YES or NO)?" when the "CONFIG" utility first loads. If you prefer to use the parameters from your existing single node RBBS-PC.DEF file, you may simply copy that file to the new .DEF files before you run the "CONFIG" utility. After loading the "CONFIG" utility, it will ask you "To which copy of RBBS-PC will these options apply (1 to 36)?" and you should respond with node number (or copy) you want to configure. Here are the parameters that will have to be changed for each node of RBBS- PC you intend to use. This example is for a system with two nodes. Node DEF file--> RBBS1PC.DEF RBBS2PC.DEF RBBS-PC CPC17-2A Page 239 Default Configuration Parameters Parameters Parameters -------------------------------- ----------- ----------- Communications port to be used by RBBS-PC ---- COM1 COM2 File RBBS builds dynamically to open a 'door'- D:RCTTY1.BAT D:RCTTY2.BAT When a 'door' closes, file to re-invoke RBBS - D:RBBS1.BAT D:RBBS2.BAT Maximum number of concurrent RBBS-PC's ------- 2 2 These are in CONFIG as parameter 221, parameter 103, parameter 104, and parameter 161 (respectively). Please note that the preceding parameters are located on different pages of the "CONFIG" utility. 4. DESQview Setup Default Settings ---------------------------------- The first step in setting up DESQview for use with RBBS-PC is specifying the default settings for DESQview. DESQview has a program called SETUP.EXE that you should run. After the SETUP program loads, press RETURN for the Advanced Setup Procedure followed by a "P" for Performance defaults. Here is an example of the settings you should use. Advanced Setup: Performance Task Processing Time (clock ticks) Foreground: 4 <----- Background: 3 <----- Memory Usage (in K bytes) DESQview Scripts: 1 Playback Scripts: 1 Learn Scripts: 1 System Memory: 12 High Speed Comm? (Y/N): Y <----- Jump Scroll? (Y/N): N Swap to Disk? (Y/N): N The arrows above refer to changes from DESQview's default settings. NEVER indicate more clock ticks for Background processing than you are using for the Foreground processing. DESQview will automatically increase the amount of Background clock ticks whenever there is little demand for Foreground processing. This is the case when running RBBS-PC in the background and doing word processing or a similar task in the foreground. This feature cannot function properly if the Background clock ticks are set higher than the Foreground clock ticks. Setting the High Speed Comm default to YES will make communications interrupts the highest priority. This will keep file transfers going smoothly for your callers while you are doing other tasks or operating multiple nodes of RBBS-PC. RBBS-PC CPC17-2A Page 240 5. Adding RBBS-PC to DESQview's "Open Window" Menu --------------------------------------------------- Refer to the section "Adding Your Own Program" in the DESQview manual. You will need to "Add a Program" for each node of RBBS-PC you intend to operate on your system. You may name the programs N1, N2, etc. N1 will load the batch file RBBS1.BAT, N2 will load RBBS2.BAT and so on. Use the following settings for each node (or copy) of RBBS-PC you install. Add a Program Program Name . . . . . . RBBS-PC [node 1] Keys to use on Open Menu N1 Command to Start Program RBBS1.BAT Path to Data Files . . . D:\RBBS (subdirectory RBBS1.BAT is located in) Memory Size (in K) . . . 288 (see "Memory Considerations" below) Window Position . . . . Row 0 Column 0 Height 25 Width 80 Script Buffer Size (in bytes) 1000 Options: OFF ON---> Displays graphics information OFF ON---> Uses its own colors OFF ON---> Allows keyboard type-ahead OFF ON---> Allows script type-ahead OFF OFF To toggle an option ON or OFF, move the cursor to the option with the TAB key and press the + key to the right of the numeric pad. An option is ON whenever it is highlighted on your screen. Only the first four options on the right hand side should be highlighted before pressing RETURN to end the "Add a Program" session. Leaving the "Displays graphics information" option set to OFF (not highlighted) may cause your system to lock-up when you attempt to open another window. 6. Memory Considerations ------------------------- Current versions of DESQview require a little under 162k of your system's memory. This leaves you with about 478k to operate RBBS-PC on a system with 640k. Specify a minimum window size of 270k for each node of RBBS-PC you intend to operate. If you choose to use RBBS-PC's external protocol drivers for file transfers you can use SHELL or EXIT. SHELL requires 370k as the minimum partition size. It is necessary to use EEMS memory to run two copies of RBBS-PC in the same machine. If you use the second node for SYSOP duties only, the above configuration should work nicely. When using the second node for SYSOP duties an additional modem and an additional RS-232 interface is not required -- all you have to do is use CONFIG to set up the .DEF file for the node you are going to use for SYSOP duties as using COM0. Failure to do so will prevent your second node from loading properly. 7. Expanded Memory ------------------- If you are using an "Expanded Memory" board that allows more than 640k to be used for programs, the constraints discussed in the previous section may not apply. Specify a window size of 370K for each node of RBBS-PC and invoke the external protocol drivers by SHELLing. For information on running programs in expanded memory, refer to the manuals for DESQview and your particular memory board. 8. How to AUTOEXEC RBBS-PC From DESQview ---------------------------------------- Refer to the section "Learn: DESQview's Keystroke Macro Feature" in the DESQview manual. A script assigned to the ! key (on the DESQview menu) has RBBS-PC CPC17-2A Page 241 a special meaning. It is performed at the time you start up DESQview, immediately after the DESQview menu appears. This is called a STARTUP SCRIPT. You should "Learn" the Startup Script with no windows open and with the DESQview menu displayed to be sure it will play back properly. Use this particular script to load N1, N2, etc. of RBBS-PC. If you load DESQview from your AUTOEXEC.BAT file, RBBS-PC will load from DESQview automatically. This can be handy if there is a power outage while you are away and no one is around to re-load RBBS-PC when the electricity returns. Finally, it's suggested that you open the window(s) for RBBS-PC prior to opening a window for any other application software. 9. RBBS-PC Technical Support For DESQview ----------------------------------------- The preceding configuration has been given to every SYSOP that has contacted our bulletin board system regarding DESQview usage with RBBS-PC. It has, in every case, solved their problems with DESQview and RBBS-PC. If you follow these instructions and continue to have difficulties, please contact us and we will do our best to help out. John Taylor SYSOP, Indiana On-Line (tm) (812) 332-RBBS /data (812) 332-1110 /voice Additional Notes: Two Quarterdeck utilities, STDERR.COM and LDFILTER.COM are distributed with RBBS-PC. STDERR.COM should be started up in your autoexec.bat file when you bring up DESQview. STDERR.COM was written by Quarterdeck Office Systems to compensate DOS' inability to redirect the standard error output to the same device that the standard output device had been redirected. If are running something remotely and an error occurs, STDERR.COM allows the error to be displayed at the remote user's end and not simply on the PC that is running RBBS-PC under DESQview. LDFILTER.COM should be started up every time you open a window in DESQview. LDFILTER.COM was written by Quarterdeck Office Systems to compensate for the memory mismanagement of the BASIC compilers. If you try to "SHELL" to an external routine the error that there is not enough memory to SHELL with is issued. LDFILTER.COM prevents this error condition by preventing the code generated by the BASIC compilers from mis-managing memory. RBBS-PC CPC17-2A Page 242 APPENDIX C -- RBBS-PC in a MultiLink Environment ------------------------------------------------ RBBS-PC only runs under Multilink versions 4.0, 3.02 and earlier. CONFIG's allows the SYSOP to tell RBBS-PC that it will be running in a MultiLink environment. This is ESSENTIAL when running RBBS-PC under MultiLink. CONFIG allows the SYSOP to specify what MultiLink terminal type code to pass to MultiLink whenever RBBS-PC exits to DOS via a "Door". Page 15 of the MultiLink documentation specifies the various terminal type codes. When a SYSOP indicates that "doors" are available (via parameter 101 of CONFIG) and RBBS-PC is to be run under MultiLink, the SYSOP is asked to select the MultiLink terminal type that RBBS-PC is to inform MultiLink to expect when MultiLink is given control of the "Door." RBBS-PC has been tested running two copies of RBBS-PC under DOS 3.2 and MultiLink Advanced (versions 3.02 and 4.0) on an IBM PC which had a mother- board containing 256K and an AST Comboplus board with 384K (a total of 640K). However, to do this RBBS-PC must be re-compiled (see Appendix Y). The "autoexec" file was named AUTOEXEC.BAT and contained the following parameters MLINK /9,266/9,266 NOTE! ==>RBBS-PC must be recompiled with C:512 in order to run in a 268K partition under MultiLink. As released, RBBS-PC is compiled with the parameter C:4096 which requires a MultiLink partition of 270K. Of course, to SHELL to the external protocols, the partitions must be about 440K. It is important to avoid doing several things when running RBBS-PC under MultiLink. First, NEVER RUN MLSLICE! This is because MLSLICE hangs off the PC's timer chain and the code generated by the BASIC compilers violates all sorts of DOS conventions whenever it is utilizing the PC's speaker (i.e. as when RBBS-PC pages the SYSOP). In so doing, the code generated by the BASIC compilers is incompatible with programs that do follow DOS conventions. Second, NEVER use the DOS "PRINT" command! This is because there is a bug in the code generated by the BASIC compiler that causes the system to hang if a compiled BASIC program is running and DOS is printing something. This bug has been corrected in the BASIC compiler that was used to generate RBBS-PC.EXE that is distributed. However the version of RBBS-PC that you get (if other than from CPCUG) may not have this bug corrected. This is a bug that occurs independent of running MultiLink. Third, check your Intel 8088 chip's copyright date by opening up the cover and locating the 8088 chip. If the copyright date printed on the chip is 1978 (i.e. pre 1981), REPLACE THE INTEL 8088 CHIP!!!!! The 1978 Intel 8088 chip had several design flaws that will cause your system to lock up occasionally. One of these design flaws allowed interrupts to occur while stack switching (something that will happen running multiple partitions doing disk I/O under any multi-tasking DOS add-on such as MultiLink or even IBM's TopView). Don't blame MultiLink for the flawed Intel 8088 chip that IBM put in your PC! It costs about $70 ($35 for the chip and $35 for labor) and takes about 15 minutes to have the 1978 Intel 8088 chip replaced. In fact, if you are going to replace your 1978 Intel 8088 chip, you might consider the newer (and 5% to 10% faster) NEC V20 chip. Fourth, DON'T USE "BUFFERS=" in the CONFIG.SYS for DOS! This may be an "old wives tale," but I am convinced (but can't prove) that there are incompatibilities between the code the BASIC compiler generates, DOS's use of "BUFFERS=", and MultiLink. RBBS-PC CPC17-2A Page 243 Fifth, DON'T ALLOW MNP PROTOCOL for file transfers. An incompatibility exists between the Software Link, Inc.'s Multi-Link and MICROCOM's MNP software. Until the respective vendor's resolve this, don't use both products concurrently! Sixth, RBBS-PC will only run in Background 1 or Background 2. Finally, DON'T RUN PROGRAMS THAT USE THE BASIC "RUN-TIME" LIBRARY, and always invoke the BASIC interpreter with the command BASIC /C:0! Both the BASIC interpreter's handling of communications ports and BASRUN.EXE seem to violate enough DOS conventions to "lock up" MultiLink. When RBBS-PC is told that it is running in a MultiLink environment via CONFIG parameter 162, RBBS-PC will automatically do the following: 1. When re-cycling, it will automatically enque on the correct MultiLink resource ID for the communications port defined in CONFIG for that copy of RBBS-PC to use. 2. When re-cycling, it will automatically tell MultiLink that this is a type "9" partition (i.e. MultiLink is NOT to handle the communications port). 3. When exiting to DOS via a "door", RBBS-PC will automatically tell MultiLink to start handling the communications for this partition (COM1 or COM2) and what type of terminal was defined in CONFIG that would be on the communications port (MultiLink terminal types 1 through 12). Manually, it is possible to bring up and run one copy of RBBS-PC under MultiLink. The only way that I have been able to bring up two copies of RBBS-PC successfully (one copy running in each of two partitions) was to bring them up via AUTOEXE1.BAT and AUTOEXE2.BAT files. It appears that during the MultiLink initialization sequence when the partitions are being established and the "AUTOEXEx.BAT" files are being invoked that MultiLink doesn't get "confused" and lock up with a second copy of RBBS-PC present. If using Multi-Link to run multiple nodes in the same machine under DOS 3.x or above, it is recommended that the SYSOP execute SHARE.COM prior to starting multiple RBBS-PC nodes under Multi-Link and specify FILES=20 in the CONFIG.SYS file. RBBS-PC CPC17-2A Page 244 APPENDIX D -- RBBS-PC in a CORVUS Network ----------------------------------------- RBBS-PC uses the standard Corvus SEMAPHORES when sharing files among multiple copies of RBBS-PC within a Corvus Network. This is accomplished via the MS-DOS utility driver, DRIVEC2, that Corvus supplies with its network. On a multi-server Corvus network (i.e. where there are multiple shared hard disk drives) all PC's that are running RBBS-PC within the Corvus network MUST have their "home volume" on the same server. Corvus maintains each PC's semaphores on that PC's "home volume". In order to "share" files among various PC's in a Corvus network, all the PC's that are "sharing" must also be looking at the same set of semaphores. In a single-server Corvus network this is not a consideration because there is only one "home volume." RBBS-PC has been only tested with the Corvus CONSTELLATION II interface cards and software that Corvus provides for the IBM PC. RBBS-PC should work with both Corvus' older "flat cable" network as well as their newer OMNINET twisted wire pair cable network when running CONSTELLATION II software. It is entirely possible that RBBS-PC would work with some combination of both Corvus network types as long as they were running CONSTELLATION II software. It should be self-evident that every PC within a Corvus network running RBBS-PC must have a Corvus interface card. If multiple copies of RBBS-PC are running in a Corvus network that is using older Corvus software (i.e. NOT running the CONSTELLATION II software), the interface cards must, at least, all have the CONSTELLATION II ROM. RBBS-PC is tested only to run on IBM PC's within a Corvus network. Clearly an IBM "clone" that can run IBM's DOS, RBBS-PC.EXE, and is supported by Corvus' network should also work. However, such configurations (and their many variations) are not part of the environment within which RBBS-PC is tested and supported. RBBS-PC CPC17-2A Page 245 APPENDIX E -- RBBS-PC in ORCHID or AST PCnet NETWORK ---------------------------------------------------- RBBS-PC can be implemented on an Orchid PCnet or AST PCnet Network environment. It is assumed that the necessary network hardware is installed correctly. The following discussion describes a network currently in operation and receiving more than 1000 calls per week on two telephone lines for the Computer Connection of Virginia Beach. The hardware and software was: 1. 80286 based SERVER with 512K running at up to 9 mhz with: Parallel-Serial Board on the AT with a serial port addressed as COM1 AST Rampage memory board configured with 2 megs of expanded memory Monochrome Adapter with parallel printer port PC Net adapter addressed as 0080 with default jumpers Hard disk that can be divided into multiple volumes Single High Density [1.2 meg] floppy disk External modem and cable connected to COM1 2. 8088 based WORKSTATION with 640K running at up to 8 mghz with: multifunction board with COM1, a clock, and parallel port PC Net adapter addressed as 0011 with default jumpers Color Graphics Adapter Two 360K floppy drives External modem and cable connected to COM1 3. Software - Operating System = DOS 3.1 network-wide Network Software = Orchid PC Net 3.0a Disk Caching Software = Orchid CACHE.EXE version 2.2 RAM Disk = AST FASTDISK Installation procedures --- 1. Preliminaries 1. Backup hard disk, system and network disks. 2. If your hardware is different, be sure to resolve INTerrupt conflicts with the PC NET adapters. Disable second serial or parallel ports in all PC's. 2. Using the WORKSTATION, boot with DOS 3.1 then 1. Create the SERVER and WORKSTATION boot disks with SPCGEN and UPCGEN commands, respectively. 2. Copy device drivers for the hard disk, for the RAM disk, and for Expanded and Extended memory (REMM.SYS and REX.SYS) to the SERVER boot disk as well as CACHE.EXE. Place the following CONFIG.SYS file for the SERVER: device=spc.com <-- Network SERVER driver device=REMM.SYS <-- Expanded memory driver device=rex.sys 1024 <-- 1MB Emulated extended memory device=fastdisk.sys 1024 512 128 /e <-- RAM disk in extended memory 3. Place the following commands in the AUTOEXEC.BAT file: disk13 <-- Network for floppy disk use cache [drives] d=128 x=896 /r <-- 128K cache of DOS memory & 896K of EMS memory for SERVER drives to reduce the number of disk accesses spcbio 138023 <-- Tell network of interrupts used 4. Using the SERVER, boot with the newly created SERVER boot disk 1. Run the network program SPCINST. 2. After naming all the available drives on the server, assign all the hard drive volumes to the WORKSTATION # 11 and them all READ/WRITE capable. "Remote Execution" need not be enabled. 3. The SERVER will then reboot and the network will have the final configuration as outlined above. 5. Boot the WORKSTATION with the newly created WORKSTATION boot disk and: 1. Add FILES = 16 to the CONFIG.SYS file for the WORKSTATION. 2. Use the network program UPCINST to communicate with SERVER # 80. 3. "Map" in all the drives that were assigned by the SERVER. 4. The WORKSTATION will reboot so the changes can take effect. RBBS-PC CPC17-2A Page 246 5. After the WORKSTATION reboots, do a DIR C: to see if the directory on the SERVER hard disk can be read. If not, recheck cables, plug-in cards for INTerrupt conflicts, and network adapter cards to verify all jumper settings. If necessary, run the SELFTEST and NETTEST diagnostics for the network adapter cards. Also, demonstrate the ability to copy files across the network to and from the server then verify the transfer using the COMP command. 6. Assuming that you are able to do a DIR across the network and copy files to and from the SERVER, you are then ready to run CONFIG.EXE of RBBS-PC. Run CONFIG and confirm use of RBBS-PC in a multinode environment. Assign the number 1 Node to your SERVER. 1. Assign all welcome, bulletin, help and menu files to the SERVER's RAM drive so the workstation may access them in the fastest way. 2. Store FILESEC, PASSWRDS, MESSAGES, USERS and other sensitive files in a non-downloadable but sharable drive volume on the SERVER so the workstation may have read/write access to them. 3. Select a location for the SERVER's CALLERS file and the WORKSTATION's. 4. Reflect the node numbers in the BATch file names, e.g. RCTTY1.BAT and RCTTY2.BAT, RBBS1.BAT and RBBS2.BAT. 5. Choose PCNET as the environment that you are running RBBS-PC under. Other Considerations-- VDISK or Extended memory, which is not-emulated memory, should not be used on the SERVER but can be used on the Workstation. The network configuration most likely to remain operating with very few problems is DOS 3.1, Orchid 3.0a PC NET software and CACHE.EXE version 2.2 and an Expanded/Extended memory combination using the new Lotus/Intel/Microsoft EMS memory boards. Two nodes can be efficiently set up using the SERVER in non-dedicated mode but the danger is that if the SERVER locks up, the whole system locks up. The sample PC Net system is set up in this fashion but it is an economical approach to a two node system which has been functioning quite well with minimal problems. Do not run software on the SERVER that is known to cause problems especially memory resident utilities. There is a potential for files being CROSS-LINKED in any read/write sharable environment. Frequent backups are to be very strongly recommended. Because of wide variety of hardware combinations and possible network permutations, the above is intended ONLY as general guidelines to be followed when installing RBBS-PC on your Orchid network. Rob Cecchino Sysop, Computer Connection (804) 481-1824 at 1200/2400 for assistance. RBBS-PC CPC17-2A Page 247 APPENDIX F -- RBBS-PC in an Alloy PC-SLAVE/16 Environment --------------------------------------------------------- The PC-Slave is an IBM compatible computer on an expansion card manufactured by Alloy Computer Products, Inc. of Framingham, MA 01701. Their telephone number is (617) 875-6100. Adding PC-Slaves converts the PC from a single CPU to a multiple CPU, all under the control of the main or host PC. Each slave can run RBBS-PC (or other programs). A. THE ADVANTAGES: Compared to other means for running multiple RBBS-PC's, the advantages of slaves are: 1. SPEED -- Each copy of RBBS has a dedicated computer and therefore runs very fast compared to multi-tasking products like Multi-Link, DesqView, or Top View. 2. SHARED FILES -- Each bulletin board can share files, including the users and messages. The PC Slave system acts like Orchid's PC-Net network for record locking. 3.EXPANDABILITY -- You can have up to 31 slaves. The big advantage over Multi-Link is that you have faster boards and can expand beyond 2 boards. The big advantage over networks is that you do not have to add another PC, just another slave. The power supply and cooling capacity of a PC-2 or XT limit you to adding only 2 slaves. An AT can have up to five. You can buy PC compatibles that have more expansion slots. You can also get an external hard disk with expansion slots. Or you can buy an expansion chassis. 4. COSTS -- It is far cheaper to expand using PC-Slave/16's than a network. The PC-Slave lists for $900 and can be purchased for significantly less. Other networks require not only a separate PC but also a "network" card of some sort which puts the costs of each port well above $2,000. 5. DEDICATED PC IS NOT REQUIRED -- Your PC can remain free for you to use while slaves run the bulletin boards (or run another copy of the bulletin board). You do not degrade performance on the slaves, except for contention for the hard disk and that can be mitigated by using disk caching. 6. EASY SNOOP. Using Alloy utilities GIMME and VIEW, you can view the session on any slave and attach your keyboard to it. You can also install a dumb monitor to any slave. B. THE DISADVANTAGES: The disadvantages of a slave system are: 1. COMPATIBILITY --Not all hard disks are compatible with the slaves. Hard disks known to be compatible include the Seagates, Priam 60 meg, Bernoulli, and Maxtor hard disks, as well as the Alloy line of hard disks. Hard disks definitely not compatible include all models of US Design. 2. ONLY TWO SHARED DRIVES CAN BE WRITTEN TO -- At most two drives can be shared for writing. All drives can be read from any slaves, but to write on a non-shared drive, no other can write to it. C. OVERVIEW OF SETTING UP A PC-SLAVE/16 RBBS-PC: Five easy steps on how to install RBBS-PC in a PC-Slave/16 environment (Note that the PC Slave system requires a special configuration for RBBS-PC): STEP 1 -- You will have to purchase multiple telephone lines. They can be made to roll so that only one number is called, and if busy, the call will roll over to the other lines. RBBS-PC CPC17-2A Page 248 STEP2 -- Install the slaves. Remember to set switches on the slave boards that number them consecutively. See the PC-Slave documentation for details. STEP 3 -- Install the software. The Alloy PC-Slave has to have special Alloy software called NTNX to coordinate the slaves and process requests for shared resources. You also have to run an Alloy routine to prepare your hard disk for use with the Alloy slaves. See the PC- Slave documentation for details. STEP 4 -- Install a modem with no pin 22. Pin 22 used to be required with RBBS-PC in order to answer the phone. On the slaves, pin 22 CANNOT be connected, or else the slave will continuously reboot. However, newer slaves support pin 22. STEP 5 -- Configure RBBS-PC using CONFIG.EXE with the following parameters: (a) use COM2 (parameter 221) (b) Via parameter 29 tell RBBS-PC it is running on an IBM compatible rather than a PC, XT, or AT. (Lie and tell RBBS-PC you have a Compaq Plus.) (c) Use CONFIG parameter 161 to set the maximum number of bulletin boards to as many boards as you intend to install (rather than the number you are currently running. This makes expansion easier.). (d) PC-Net is the multi-user environment you will be running under and should indicate so via CONFIG parameter 162. (e) Set up the RBBS-PC files. An easy way to configure the multiple RBBS-PC's is to put each one in a separate subdirectory, e.g. "RBBS1" for the 1st node, "RBBS2" for the second, etc. Inside each subdirectory will be the callers file for that node and the DEF file (RBBS1PC.DEF, RBBS2PC.DEF, etc.). The DEF files can be the same. Make the default drive on each slave be the right subdirectory. Path over to where the RBBS-PC.EXE is stored. Invoke each RBBS-PC by using its node number, e.g. "RBBS-PC 1", "RBBS-PC 2", etc. You can set up an autoexec for each slave that brings up the boards automatically upon system boot. Please note that the NTNX software is very vulnerable to any RAM resident software. You should install the Slaves with no additional software present and carefully test any resident software you want to run with it. D. A DETAILED DESCRIPTION OF SETTING UP A PC-SLAVE 16 RBBS-PC: Hardware Limitations: 1. Two PC/Slave 16 cards per XT box or five in an AT maximum otherwise you'll be buying power supplies frequently. An expansion chassis for four cards (Alloy Plus4) or expansion chassis for up to twelve cards will be needed for bigger systems. Expansions boxes can be daisy- chained to up to thirty one Nodes or workstations, if needed. 2. PC/Slave 16 cards do not support PIN 22 for Ring Detect. You must be able to set your modem to AutoAnswer as well as NOT have PIN 22 wired on your modem cables; if PIN 22 is connected, each callers RING will reboot the Slave. 3. No clock on the PC/Slave 16 card. The Slave gets the Time and date from the main system clock and so one must be available. 4. A terminal such as a Kimtron KT-7/PC or Alloy PCST is needed if you want to work on a slave the same as you would on the host computer (but not if RBBS-PC CPC17-2A Page 249 you just want to view activity on slaves occasionally). Other terminals will work but may not support all of the IBM extended graphics codes. For a multi-node RBBS-PC, one terminal can be used with an A-B-C-D switching box to 'dial in' to the node you wish to work with. 5. The Slaves' CPU [NEC V20 @ 8 mhz] shuts down when writing to the hard disk. This creates problems with timeout errors on uploads. Upload problems can be eliminated by using the write buffer option in NTNX 1.64 or higher (/B). The problem can also be alleviated by using a fast hard drive supported by Alloy. Also, the hard drive must be formatted with the most efficient interleave setting and driver. Hard drives that work without significant upload timeout errors have been formatted with either Golden Bow's Vfeature Deluxe or Priam's formatting software; this problem is especially noticeable on AT systems and not too much of a problem on small XT systems. Seagate, Bernoulli Box, Maxtors, and Priam Inner Space drives seem to work fine with the Alloy PC/Slave-16 cards. Software Limitations: 1. ATNX runs Orchid PC Net applications but NTNX is more versatile and will run applications for Novell's Advanced Netware, MS-Net, AND Orchid PC Net with proper file locking. NTNX has had less problems with file corruption and cross-linking than ATNX after polling current sysops using Alloy Slaves. 2. ATNX and NTNX will allow users working on Slaves to easily and routinely have read/write access on only TWO hard drive volumes. 3. ATNX and NTNX have difficulty keeping track of system date and time when "certain" programs are run on the Slave. With RBBS-PC, running external such as Ymodem and WXmodem cause the time and date on the Slaves to go awry. Also, WXMODEM does not work in upload mode on Slaves due to a timing problem in the initial handshake. Alloy's solution to this problem is a file called UPTIME.COM, which is run on the HOST, but I have had very poor results with it. The problem seems to be most identifiable on AT class machines. For the optimum system flexibility you may want to buy Alloy PC/Slave-16N cards which have the special PAL chip for NTNX/Novell compatibility and NTNX software. RBBS-PC, however, will run fine without the PAL chip even under NTNX. Some nice additional utilities for the Slaves, including special diagnostics, are found in the separate PC-Plus Advanced User's Kit and are worth having. A single Kimtron KT-7/PC terminal or other smart terminal may be obtained right away but is not necessary for the bulletin-board-only system as one can always sign on from remote for answering mail; pay special attention to the terminal-to-Slave cable as it is non-standard and you'll probably wind up making it yourself for less than $5 in parts -- one end is a male 9-pin D-shell and the other is 25-pin RS232 male connector. For a two to four node system, obtain a T-Switch box from Inmacs or Radio Shack to hook the terminal as COMMON and Slave consoles. The computer to house the Slaves, called the HOST, should be the quickest CPU speed that you can obtain. All PC Slaves/16 should be purchased with 1 megabyte of onboard RAM. Installation: 1. Format your hard drive with either DOS 3.1 or 3.2. 2. Divide the hard drive into multiple volumes of standard DOS size (less than 32 megabytes). RBBS-PC CPC17-2A Page 250 3. Install NTNX or ATNX and the Slaves as is written in the Alloy manuals. Choose the default settings for everything. Use 512K on the 1 megabyte PC/Slave for caching and the other 512 to run RBBS. Depending on how the board is configured, you may need to set switches so that 512 is used to run applications. Use 4K for the Host PC caching. Allocate 25 files per each Slave + 64 for the maximum number of open files. 4. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the HOST as follows especially if you do not plan to use the HOST as a Node for RBBS-PC: CONFIG.SYS device=NX.SYS - NTNX driver (must be first!!) device=hard_drv.sys - Your hard Disk driver FCBS = 32,32 - File Control Blocks increased buffers = 20 - DOS buffers files = 32 - Number of OPEN files on HOST device = ANSI.sys - Extended graphics driver AUTOEXEC.BAT NTNX - NTNX driver fm 3 - Level of File protection prompt $p$g - customized dos prompt path = ........ - set path to the NTNX files 5. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the Slaves as follows: CONFIG.U0x under DOS 3.2 FCBS = 32,32 buffers = 10 files = 30 device = ansi.sys shell = C:\COMMAND.SLV C:\ /P /E:800 device = ANSI.SYS Of special note, the SHELL statement has been used to expand the environment space on the Slaves. This corrects a problem seen with random RBBS lockups or getting Out of Memory errors; external protocols and DOOR programs, given time, stop running due to memory problems if one doesn't use this SHELL statement. Under DOS 3.1, set /E:50 [= 50 paragraphs] and under DOS 3.2, set /E:800 [= 800 bytes]. AUTOEXEC.U0x fm 3 prompt $p$g path = .......Set the path to the NTNX files and to the 'home' directory for this node on the SHARED drives cd\RBBS0x Change to the RBBS-PC directory for Node x RBBSx.BAT Invoke RBBS-PC for Node x 6. CONFIG parameters for the slaves, must be the following parameters: Parameter 29 (Type of computer): Compaq Plus. Parameter 224 (Number of rings to wait before answering): 0. Parameter 162 (Environment): Orchid PC Net. Parameter 221 (Communications port): 2. Maximum number of users: at least as many slaves as you have, plus one if you plan to run a node on the host. You can specify more (up to 36) if you want to plan for expansion. 7. Set up RBBS-PC as follows: Create subdirectories \RBBS01, \RBBS02, \RBBS0x... on a shared drive. Create subdirectory \MAIN for your upload directory, answers to questionnaires, comments. RBBS-PC CPC17-2A Page 251 On a cached drive, place all static RBBS-PC files such as MENUs, HELPs, PASSWRDS, TRASHCAN, external file transfer protocols. RBBS- PC.EXE and CONFIG.EXE go here as well. On the second SHARED drive, make a subdirectory \COMMON for MESSAGES, USERS, CONFENCE, and conference message/user files. If you plan to use DOORS, especially Bob Westcott's DOORWARE, create a subdirectory called \DOORS on the SHARED drive. Run CONFIG and create RBBSxPC.DEF files for all your nodes. Remember that you will run multi-user under PC Net. To answer on RING zero, the modem serial port on the Slaves must be addressed as COM2 and not COM1. Double-check file locations! Put your static text files in the same subdir as MESSAGES and USERS and make it the default subdirectory Copy RBBS1PC.DEF to RBBSxPC.DEF for each node that you hope to have then re-edit each .DEF file to customize Node numbers such as RCTTY1.BAT, RBBS3.BAT, etc. Copy the RBBSxPC.DEF file to the matching subdirectory. If you don't wish to edit the .DEF files, place RBBSxPC.DEF on one shared drive and place the dynamic RBBS-PC files on the other shared drive; be sure that you have at least logged into that other SHARED drive's subdirectory, using the AUTOEXEC.U0x before starting RBBS-PC or else RBBS-PC will not find those files. Temporary files used for transfer or Verbose ARC listing are created on the default subdirectory automatically. You may assign CALLERS as either one file for all nodes or one CALLERS file for each node located in the default directory. To use Sysop Function 7 (Remote Drop to DOS), RBBS-PC must find COMMAND.COM. PC-Slave/16's, however, use COMMAND.SLV as the command processor; copy COMMAND.SLV to COMMAND.COM, place it on a cached drive, and tell CONFIG where to find it. Be careful using this Sysop function with the Slaves as you will lock up the Node if you lose carrier; WATCHDOG is incompatible with the Slaves. Additional tips/hints: 1. Avoid using any memory resident utilities. They may interfere with Slave operation. 2. A program on the Advanced Utilities disk called SEE.COM allows callers on any Node to be viewed from the HOST. 3. Norton's Editor or WordPerfect Corporation's Programmers Editor from the WordPerfect Library is used for editing operations on the system, especially for maintaining the fixed-length directory of the file management system. Not many other editors, except EDLIN, can be used reliably. 4. Easy to forget but don't as it will be a source of frustration -- plan out your file locations on paper before actually setting up the system. 5. Backup your system frequently! If you have any questions or problems, feel free to leave a message on Ken Goosens system (703) 978-6360. RBBS-PC CPC17-2A Page 252 APPENDIX G -- RBBS-PC and 10 NET Network ---------------------------------------- Starting with RBBS-PC CPC15-1A support for Fox Research's' 10 Net Network is being provided. Since this is the first release with this support we have very little that we can offer in tuning support for 10 NET. We selected to use the Semaphore locking mechanism that we have used in the other networks and therefore you must specify the following parameters on the Superstation in your 10 NET network. LOGINS=x 1 for every node on the system OPENFILE=xxx 10 for every node running RBBS-PC SHAREFIL=16 (This is the default you can add more if you want) LOCKS=x 3 SEMA=xxx 3 for every node running RBBS-PC You will also need to run NETSU and specify option 6 (DOS file sharing). Please note that these values should be in addition to any parameters you may have already specified for other User stations and other uses of your 10 NET network. And you can always make the values larger in attempting to improve performance. RBBS-PC CPC17-2A Page 253 APPENDIX H -- RBBS-PC and the Hearing-Impaired ---------------------------------------------- Telecommunications Devices for the Deaf (TDD's) use the Baudot character set (i.e. 5-bit) and utilize modems that transmit at 45 baud and do not generate a carrier signal. This is because such devices were initially adaptations of surplus Western Union TTY machines for telephone communications. The widespread use of Baudot devices by the hearing- impaired, the previous high cost of computers and modems, and the lack of software designed for electronic communications, has impeded the change to ASCII communications by the hearing-impaired community. Equipment manufacturers have also made it difficult for the deaf to change. When TDD's with ASCII code transmission capability began to be offered, the majority of manufacturers limited them to only 110 baud and put disclaimers in their manuals that said ASCII was available for use but that "computer language" was "less reliable" and hard to use. Their limiting of the TDD's output screen to 12 to 20 characters further compounded the problem because the screen would overwrite several times to display one line of text from a host system. The manufacturers' "solution" to this problem was to recommend printers for communication with such "host" systems as RBBS-PC. Some units now offer both 110 and 300 baud ASCII transmission in addition to the 45 baud Baudot. Unfortunately, these typically have only 20 character screens. In December of 1984, Ted Janossy of Rochester, Minnesota, sent me a three- page letter describing the above situation. Ted's letter motivated me to test and verify the "ring-back" feature of RBBS-PC in CPC12-4A. It had not been tested in earlier versions because I had assumed (presumptuously and insensitively) that "real SYSOP's don't use ring-back RBBS-PC's." Ted's letter awakened me to the potential of RBBS-PC to facilitate communications among the hearing-impaired. In the awakening I also had a chance to look down at my own feet of clay. RBBS-PC can be configured to answer calls only after a specified number of rings (i.e. 15). The telephone companies wire the homes of the hearing- impaired such that when the phone rings, the lights within the house flash on and off. With RBBS-PC a SYSOP can specify the number of rings RBBS-PC is to wait before answering the phone automatically. Setting this number high enough allows someone with a hearing impairment time enough to get to the PC running RBBS-PC. Pressing the PC's function key 5 (F5) causes RBBS-PC to answer the phone immediately. The caller would know that someone was at the keyboard because RBBS-PC answered the phone in less than the agreed- upon number of rings. The caller would log onto RBBS-PC normally and the person at the PC keyboard would be able to see who it was. If the person who was called wanted to "chat" with the caller, all they would have to do would be to press function key 10 (F10). If RBBS-PC didn't answer the telephone within the agreed-upon number of rings, the caller would know that whomever was being called couldn't come to the keyboard. The caller would then log on and leave a message. RBBS-PC CPC17-2A Page 254 APPENDIX I -- RBBS-PC and the IBM PCjr -------------------------------------- RBBS-PC adheres to the Hayes standards for autoanswer applications that are described in Section 9, "Writing Programs for the Smartmodem 1200," of the SMARTMODEM 1200 HARDWARE REFERENCE MANUAL. Under the section entitled "Additional Program Considerations" Hayes recommends that autoanswer applications (like RBBS-PC) "... force the modem to answer the call (ATA) rather than allowing the modem to automatically answer...." Beginning with CPC13-1A, RBBS-PC no longer REQUIRES the Ring Indicator signal from the modem (pin 22) in order to answer the phone (except if parameter 224 of CONFIG is non-zero). Here are some facts about the PCjr: 1.The PCjr's external modem interface does not have a Ring Indicator signal. 2.The PCjr requires that an external modem be opened as COM1 if no internal modem is installed. However, if no internal modem exists the PCjr requires that the COM2 RS-232 registers be used even though the port has been opened as COM1. Technically this is described as using the external RS-232 asynchronous adapter as logical channel 1 (i.e. COM1) but manipulating it as physical channel 2 (i.e. COM2). This occurs on a PCjr only when an internal modem is NOT present and the external RS-232 interface is. 3. The 128K PCjr only provides 90K of usable RAM (the rest is used by DOS, the monitor's buffers, etc.). Fortunately PCjr owners can get up to 512K of RAM with "add-on" equipment (from IBM and others) in order to have enough RAM for RBBS-PC to run in. 4.The standard PCjr supplied by IBM does not have a DMA and hence can't do communications I/O simultaneously while doing disk I/O. RBBS-PC beginning with version CPC13-1A will run an IBM PCjr providing that the PCjr 1. Has at least 320K of memory. 2.Disk I/O does not occur simultaneously with communications I/O (i.e. either you have a second disk drive with a DMA or you set BUFFERS=0). 3. One of the following three modem configurations are used: An internal PCjr modem with an external Hayes modem where the external Hayes modem is used for RBBS-PC. No internal PCjr modem with an external Hayes modem used for RBBS-PC. Only an internal PCjr modem and it is used for RBBS-PC. The following discusses each of these three modem configurations supported by RBBS-PC with the PCjr. Internal PCjr Modem with RBBS-PC Using External Hayes Modem ----------------------------------------------------------- This configuration means that the PCjr has both a COM1 (the internal PCjr modem) and a COM2 (the external Hayes modem). RBBS-PC is set up to use COM2. No changes are required to for RBBS-PC for this type of PCjr configuration. CONFIG parameter 224 should be set to 0. This will cause RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC will wait for carrier detect. This is the way that RBBS-PC overcomes the PCjr's lack of "ring-indicator" signal for the external communications port. No Internal PCjr Modem With RBBS-PC Using External Hayes Modem -------------------------------------------------------------- This configuration means that the PCjr has only one RS-232 interface -- the external Hayes modem. This must be opened as COM1 but use COM2's registers to control the communications port (believe it or not that's the way IBM designed the PCjr). RBBS-PC CPC17-2A Page 255 CONFIG parameter 221 should be used to indicate that COM1 is being used. Unfortunately the current BASIC compilers (both IBM's Version 2 and Microsoft's QuickBASIC) are incapable of handling a communication port as logical device 1 (i.e. COM1) but on physical channel 2 (i.e. the interrupts are for COM2). Should this ever be fixed by either IBM or Microsoft, CONFIG parameter 29 should be used to indicate that no internal PCjr modem is installed. This tells CONFIG to make sure that COM2 registers are used to manipulate the PCjr's external communications port. Until this is fixed by the respective vendors, the PCjr user will have to run a utility like COMSWAP that exchanges the pointers between COM1 and COM2 within DOS. In either case, CONFIG parameter 224 should be set to 0. This will cause RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC will wait for carrier detect. This is the way that RBBS-PC overcomes the PCjr's lack of "ring-indicator" signal for the external communications port. Again no changes to RBBS-PC are required for this type of PCjr configuration. Only An Internal PCjr Modem for RBBS and NO External Hayes Modem ---------------------------------------------------------------- For this type of PCjr configuration, you can take the CONFIG default settings for the communications port (COM1) and specify that you are running on a PCjr (parameter 29). However, make sure that CONFIG parameter 228 specifies that the modem is to be opened at 300 baud. Of course, RBBS- PC will be only able to answer the telephone at 300 baud and send and receive data from users who log on with their communications parameters set at N/8/1 (i.e. no parity, eight data bits, and one stop bit) since RBBS-PC is limited by the PCjr's own modem's limitations. RBBS-PC already has the modem commands for the PCjr's very strange internal modem in the logic to answer the phone so no changes to the .DEF file are required. RBBS-PC CPC17-2A Page 256 APPENDIX J -- RBBS-PC Subscription Service ------------------------------------------ It seems that many people absolutely must be on the bleeding edge of RBBS- PC and demand each new version as soon as possible after it is released. Since downloading it from my RBBS-PC usually keeps my board busy 24 hours a day, seven days a week when each new version is released, and I want my board to be used to encourage and engage in discussions, I offer the RBBS- PC "Subscription Service" in order to free up my board. Within the United States for $35 (prepaid by check or money order) you can be guaranteed next day delivery of the very NEXT release of RBBS-PC just as I mail it to the CPCUG Software Exchange. The diskettes will be sent to you directly via Federal Express's "Courier-Pak" Overnight Envelope. In case you are wondering who gets the $35 it is allocated as follows: $ 25 -- Federal Express Charge for Courier-Pak 8 -- CPCUG Software Exchange 2 -- for the hassle the family puts up with and for rate changes ---- $ 35 = Total Cost Add: $5 for Alaska, Hawaii, and Puerto Rico $11 for Europe, the Far East, and Australasia Hopefully, this service will only be used by a very, VERY few! Most releases have a few fixes that get published within the first week or two that they are out. Because of this everyone is advised to check back for fixes after each release goes out. To obtain this service for the NEXT release (it does NOT apply to the current or previous releases) fill out the following form and send it along with your check or money order in U.S. funds (no purchase orders are accepted and your canceled check is your only invoice). +--------------------------------------------------------------+ | To: D. Thomas Mack RBBS-PC Subscription Service to| | 39 Cranbury Drive the NEXT release of RBBS-PC (if| | Trumbull, Connecticut any, and none are implied or | | 06611 promised by this offer) | |--------------------------------------------------------------| |Date Requested: Date Received: | |--------------------------------------------------------------| |To (Recipient's Name): | |--------------------------------------------------------------| |Recipient's Phone Number (required): ( ) - | |--------------------------------------------------------------| |Exact Street Address (no P.O. Box or P.O. Zip Code accepted) | | | | | |--------------------------------------------------------------| | City | State or Country | | | | |--------------------------------------------------------------| | Signature (required) | ZIP Code for Street Address| | | | +--------------------------------------------------------------+ Note: this is not a promise that there will be any new releases. RBBS-PC CPC17-2A Page 257 APPENDIX K -- RBBS-PC National Listing Service ---------------------------------------------- Frequent inquires are made about a "national" list of RBBS-PC's. In order to help SYSOP's (and potential SYSOP's) everywhere find configurations that most closely match their own, with the introduction of RBBS-PC CPC12-5B an additional public service was inaugurated to keep an "ACCURATE" telephone listing of all publicly available RBBS-PC systems. The success of this endeavor depends on you. If you would like a chance to stand up and be recognized, please fill out and return the following form: +--------------------------------------------------------------+ | To: Jon Martin RBBS-PC National Listing | | 4396 N. Prairie Willow Ct. Service (if any, and none is| | Concord, California implied or promised by this | | 94521 offer) | |--------------------------------------------------------------| |Please REMOVE CHANGE ADD Date Requested: | |(circle one) to your Listing. Date Action Taken: | |--------------------------------------------------------------| |SYSOP's Name: | |--------------------------------------------------------------| |DATA Phone Number (required): ( ) - | |VOICE Phone Number (optional): ( ) - | |Do NOT publish my VOICE number (please check) _____ | |--------------------------------------------------------------| |Exact Street Address (no P.O. Box or P.O. Zip Code accepted) | |(Address will not be published. For my information only.) | | | |--------------------------------------------------------------| | City | State | | | | |--------------------------------------------------------------| | Signature (required): | ZIP Code for Street Address| | | | | | | +--------------------------------------------------------------+ | Detailed System Information | | RBBS Name :_________________________________________| | Operating Hrs.(EST):_________________________________________| | Specialty of RBBS :_________________________________________| | Baud Rates :_________________________________________| | Number of Nodes :_________________________________________| | Modem Vendor/Model :_________________________________________| | Computer Type :_________________________________________| | Memory :_________________________________________| | Multi-Function Card:_________________________________________| | Monitor Vendor/Type:_________________________________________| | Disk Storage :_________________________________________| | Special Cards :_________________________________________| | DOS Version :_________________________________________| | Related Software :_________________________________________| |--------------------------------------------------------------| | Additional information/comments: | | | +--------------------------------------------------------------+ RBBS-PC CPC17-2A Page 258 APPENDIX L -- The Ark-Paradyne Modem RBBS-PC Switch Settings ------------------------------------------------------------ The ARK Modem is somewhat Hayes compatible, therefore some changes must be made to use this modem. Because of major improvements in RBBS-PC, the modem can now be used in both of its modes, Normal and Hayes. To use the HAYES (tm) mode follow this procedure: A.) Using CONFIG.EXE supplied with RBBS-PC, select and change the following parameters: Parameter 224 Number of rings to wait before answering -------- 1 Do you want ringback? (YES/NO) ----------------- NO Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATZ or ATV0Z 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0 (Note the use of "Q0" to initialize the modem) 3,4,5 Use the defaults supplied Parameter 227 Issue modem commands between rings ------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate --------------- NO Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO Parameter 245 Modem flow control uses XON/XOFF --------------- NO For the ARK 24K (not 24K PLUS) use the following switch & jumper settings: Switch 1 UUUDDUUD (where U = Up = On and D = Down = Off) Switch 2 UDDDDUDD Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E8-E9 E15-E16 E4-E7 E11-E14 For the ARK 24K PLUS use the following: Switch 1 UUUDDUUD last down = Hayes mode Switch 2 UDDDDUDD first up = auto answer off Switch 3 DUUDUDDD last three down = "auto baud" Modem Jumpers - Use the factory defaults on all B.) You can also use the ARK NORMAL mode with a fixed terminal rate. The modem talks to RBBS at 2400 and talks to your user at 300, 1200, 2400. One problem noted was that upon return from dropping to DOS, the baud rate reverted back to 2400. If you were remote and using a 1200 baud modem, things get very messy. It has been noted with some external protocols that a similar problem exists. I don't recommend this setting unless you are willing to take some risks. You must also use flow control. Make the settings as follows: Parameter 224 Number of rings to wait before answering -------- 1 Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATV0Z 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0 3,4,5 Use the defaults supplied Parameter 227 Issue commands between rings ------------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate -------------- YES Parameter 244 Modem flow control uses Clear-to-Send (CTS) --- YES Parameter 245 Modem flow control uses XON/XOFF -------------- YES The following is recommended for the ARK 24K Modem: RBBS-PC CPC17-2A Page 259 Switch 1 UUUDDUUU (NOTE 8th position) +++ Switch 2 UDDDDUDD Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E9-E10 E15-E16 E4-E7 E11-E14 The following is recommended for the ARK 24K Plus Modem: Switch 1 UUUDDUUU Switch 2 UDDDDUDD Switch 3 DUUDUUUU C.) You can also use the Hayes mode with rings set to zero but you can't use Doors or Sysop drop to DOS. (This mode has proven to be very reliable) Parameter 224 Number of rings to wait before answering -------- 0 Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATZ 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=1 3,4,5 Use the defaults supplied Parameter 227 Issue commands between rings ------------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate -------------- NO Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO Parameter 245 Modem flow control uses XON/XOFF --------------- NO The following is recommended for the ARK 24K Modem: Switch 1 UUUDDUUD (note 8th position) Switch 2 DDDDDUDD (note 1st position) Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E8-E9 E15-E16 E4-E7 E11-E14 The following is recommended for the ARK 24K Plus Modem: Switch 1 UUUDDUUD Switch 2 UDDDDUDD Switch 3 DUUDUDDD Technical comments on the Ark Modems for your interest. 1. Ark Modems can't accept any commands if the "AA" (auto answer) light is on and the phone is ringing until the number of rings equals the number set in the S0 register. RBBS-PC expects to issue a "modem answer command" when it detects a ring and is ready. If the Ark modem can't accept this command, it won't answer the phone. You therefore cannot use the ring-back system or answer on a ring greater than 1. 2. Another interesting difference is that when the modem is in the "quiet mode" (Q1) NO results will be sent to the computer. If we inquire as to the number of rings received, it responds with absolutely nothing. 3. In the Ark Normal mode, if you enter a reset command ATZ or Z, it requests a confirmation of "Confirm (Y/N) >" and you must enter a Y or else it does nothing. We can get around this with a ATV0Z which tricks this into an un-conditional reset. 4. If you attempt to operate in the ARK NORMAL mode at 2400 baud and set the DTE/CLOCK jumper to E8-E9, the modem will "downshift" to a baud rate to match the caller, which is normal. Assuming you downshift to 300 baud you must reset it with a ATZ at 300 Baud. RBBS resets it at the initial rate of 2400 baud and therefore the modem is "hung". Obviously this is not recommended. RBBS-PC CPC17-2A Page 260 The following modems were tested: 24K - ROM versions 2.21, 2.23, 2.31 24K PLUS - ROM ver 3.63. If you have questions on this modem contact: Dave Hacquebord, Sunshine Bulletin board, Tampa, Fl. Voice: 1-813-884-4267 Data: 1-813-887-3984 RBBS-PC CPC17-2A Page 261 APPENDIX M -- RBBS-PC And the Anchor Signalman Express (MK12) ------------------------------------------------------------- The following are the switch and jumper settings for the Modem. Switch 1 = Off Switch 2 = Off Switch 3 = On Switch 4 = On Switch 5 = On Switch 6 = On Switch 7 = On Switch 8 = On RBBS-PC CPC17-2A Page 262 APPENDIX N -- The Everex 2400 modem RBBS-PC switch settings ----------------------------------------------------------- The Everex Evercom 24 is an internal 2400 BAUD modem. It has 4 switches on the mounting bracket. If you are using COM1 then all switches should be in the OFF position. If you are using COM2 see the Installation Guide for the correct switch settings. The Evercom does not have non-volatile memory like the Hayes 2400 and the ATZ command will reset the modem to factory defaults. It is therefore not necessary to use CONFIG to set the Hayes 2400 defaults. Because of this major difference you must use CONFIG parameter 225 to change the standard modem defaults. Select parameters 2 and 5 and enter the command just as it is but with the addition of &D2. This will instruct RBBS-PC to add &D2 to the standard modem initialization string each time the system recycles. Please note that although the Evercom 24 manual indicates that &D2 is the default that this is a misprint in their manual and &D0 is the real default for the &D command. Parameter 7 can be ignored since they this is for battery backed up modems only. NOTE: Make sure that &D2 is inserted immediately following the "AT" when modifying parameters 2 and 5 of parameter 225! A special thanks goes to Carl Margolis (Everex) for his help in identifying these restrictions so that Evercom 24 users can now reliably use RBBS-PC. Do not select parameter 225 if you are using an Everex 1200 BAUD modem. RBBS-PC CPC17-2A Page 263 APPENDIX O -- Prometheus 2400G modem RBBS-PC switch settings ---------------------------------------------------------------- Underneath the 2400G is a bank of 10 switches that set certain operating characteristics of the ProModem 2400G. Only 3 (1,2 & 10) of these switches are currently implemented. The others are reserved for future expansion. All three of these switches must be in the off position for the 2400G to function properly with RBBS-PC. RBBS-PC CPC17-2A Page 264 APPENDIX P -- US Robotics Modems' RBBS-PC Switch Settings --------------------------------------------------------- Both the US Robotics COURIER 2400 and COURIER HST modem switch settings should be as follows: 1 2 3 4 5 6 7 8 9 10 gang switch U U U D D U U D D D UUU (Where U = Up = Off and D = Down = On) The Courier 2400 is a high quality, trouble free modem that is highly recommended and which works well with all the RBBS-PC defaults. The USR COURIER HST modem switch setting should be as follows: 1 2 3 4 5 6 7 8 9 10 gang switch U U U D D U U D D U UUU (Where U = Up = Off and D = Down = On) RBBS-PC supports both modes of the USR HST Modems. In CONFIG, specify the number of seconds between modem commands to be 1. MODE 1: ------- In the first mode of operation, CONFIG parameter 228 should be set to the highest speed you intend to support. When the HST modem detects a carrier, it sends (at the baud rate set in parameter 228) an ASCII string to RBBS-PC which contains the new BAUD rate. The modem will change it's baud rate to match that of the caller's and RBBS-PC will correctly adjust to the modem's new baud rate. The following CONFIG parameters should be set: Parameter 222 -- set to 3 to allow the modem enough time to initialize Parameter 223 -- set to 2 Parameter 227 -- set to NO Parameter 228 -- set to 9600 Parameter 237 -- set to NO Parameter 244 -- set to YES Parameter 245 -- set to NO You should also reply "NO" to parameter 225, CONFIG will show you a menu of 8 different modem commands. The ONLY command that needs to be changed is number 7, "Initialize the modem firmware". It should be: AT&A1&B0&H1&I0&M4&N0&R2&S1&Y3 The meaning of this HST-specific initialization string is as follows: &A1 = Display/ARQ result codes &B0 = DTE/DCE rate follows connection rate &H1 = Hardware (Clear To Send, Pin 5) flow control &I0 = Flow control disabled &M4 = Normal if ARQ connection cannot be made &N0 = Negotiate highest possible link rate with remote modem &R2 = Received data output to terminal on Request to Send high (Pin 4) NOTE: If your HST 9600 modem responds 961 or greater to the ATI command, substitute &R1 for &R2. &S1 = Modem controls Data Set Ready &Y3 = Nondestructive, unexpedited break signal The highest effective data transmission rate in this mode is 9600 baud. MODE 2: ------- In this second mode the USR Modem supports the MNP data compression technique which effectively transmits data over the phone at rates in excess of 17K baud. Setting up your HST to support both the standard 300, 1200, RBBS-PC CPC17-2A Page 265 2400, and the higher 9600 and 17K baud rates requires that the HST modem speed be "fixed" at 19.2K baud. The PC running RBBS-PC will communicate with the HST modem attached to it at a fixed rate of 19.2KB. The actual data link speed will default to the highest rate that the caller's modem will support. Parameter 222 -- set to 3 to allow the modem enough time to initialize Parameter 223 -- set to 2 Parameter 227 -- set to NO Parameter 228 -- set to 19200 Parameter 237 -- set to YES Parameter 244 -- set to YES Parameter 245 -- set to NO You should also reply "NO" to parameter 225, CONFIG will show you a menu of 8 different modem commands. The ONLY command that needs to be changed is number 7, "Initialize the modem firmware". It should be: AT&A1&B1&H1&I0&M4&N0&R2&S1&Y3 The meaning of this HST-specific initialization string is as follows: &A1 = Display/ARQ result codes &B1 = DTE/DCE rate is fixed at allowable rate &H1 = Hardware (Clear To Send, Pin 5) flow control &I0 = Flow control disabled &M4 = Normal if ARQ connection cannot be made &N0 = Negotiate highest possible link rate with remote modem &R2 = Received data output to terminal on Request to Send high (Pin 4) NOTE: If your HST 9600 modem responds 961 or greater to the ATI command, substitute &R1 for &R2. &S1 = Modem controls Data Set Ready &Y3 = Nondestructive, unexpedited break signal This will enable the COURIER HST to use the built-in MNP protocol at the highest possible baud rate that can be negotiated with the calling modem -- providing the calling modem is also a COURIER HST modem. The highest effective data transmission rate in this mode is 17200 baud. After replying NO to CONFIG parameter 225 and changing the initialization modem command as described above for either MODE 1 or MODE 2 for the COURIER HST, CONFIG parameter 231 should be selected in order to initialize the COURIER HST. This places the setting in the HST's non-volatile random access memory (NVRAM) and need only be repeated if the NVRAM is changed (i.e. you use the modem with applications other than RBBS-PC that change the NVRAM). For the COURIER 2400, set CONFIG parameter 228 to 2400. For the COURIER HST, set parameter 228 as specified above for either MODE 1 or MODE 2. RBBS-PC CPC17-2A Page 266 APPENDIX Q -- RBBS-PC and the FASTCOMM 2496 Turbo Modem ------------------------------------------------------- The FASTCOMM 2496 9600 and 19200 baud modems work with RBBS-PC without modifications to RBBS-PC. However some unusual quirks were noted with the FASTCOMM hardware. The modems would NOT follow terminal baud rate in the command mode if the transition was from 300 to 9600 (or 19,200) baud. Therefore, if RBBS-PC were configured to initially operate at 9600 baud, it would not properly reset after a 300 baud call. It would, however, follow all other changes within the range of RBBS-PC. If it was configured to initially answer at both 2400 and 4800 baud and it worked equally well with calls at 300, 1200, 2400, 4800, 9600 and 19200 baud for both cases. Therefore set CONFIG parameter 208 to 2400 baud! It is recommended that CONFIG parameter 224 be set to answer on one ring! Specific instructions for modem set up are as follows: 1. Using the BASIC program SETFC.BAS below, set the default modem settings. This can also be done manually from a communications program. The speed that is used to establish the default modem settings is the speed to which the modem defaults on reset and power on. It is best to do this setup at the same speed that RBBS-PC uses as its default speed, namely 2400 baud. In any case do not do it at 9600 baud. 2. Tell RBBS-PC to open the modem at 2400 baud by setting CONFIG parameter 208 to 2400 baud. 3. Use CONFIG parameter 225 to change the modem reset command from "ATZ" to "AAATZ". This string of A's resets the modem to the terminal baud rate so it can respond to the other commands. If you want to experiment, watch the modem respond to you when you change baud rates in your favorite communications program. This modem function is referred to as "autobaud". You will probably not see the first "A" echo and sometimes not the second. You should always see the third "A". Others have advised that their modems would "autobaud" from 300 to 9600 baud. Mine would not. 4. Use CONFIG parameter 225 to change the modem answer string to include X2 instead of X1 (the CONFIG default). Stan Staten has extensive experience with RBBS-PC and the FASTCOMM 2496 modems. If you have any questions regarding their use with RBBS-PC, give Stan's RBBS-PC system a call at (301) 869-7650. On the next page is STAN's SETFC.BAS program's BASIC source code to set the FASTCOMM modem. It can be run under the BASIC interperter or can be compiled using QuickBASIC from Microsoft. SETFC.EXE and SETFC2.EXE (for COM2:) can be downloaded from Stan's BBS. RBBS-PC CPC17-2A Page 267 10 'title: 'SETFC.BAS, Copyright 1986 by H. Stanley Staten 20 'SYSOP 3 WINKs BBS, 301-670-9621 30 ' 40 DEFINT A-Z 50 CLEAR 60 ' 70 ' ******************************************************************** 80 ' * ROUTINE TO INITIALIZE THE FASTCOMM 2496 MODEM'S FIRMWARE * 90 ' ******************************************************************** 100 ' 110 COM.PORT$ = "COM1" 'Change to "COM2:" for COM2: use 120 PRINT "Setting FASTCOMM 2496 firmware for RBBS-PC on " + COM.PORT$ 130 ' 140 ' ******************************************************************** 150 ' * * 160 ' * INITIALIZE THE FASTCOMM 2496 VOLATILE MEMORY. SET as follows * 170 ' * * 180 ' * AT#F = Set to factory defaults * 190 ' * AT#LCN = Set carrier detect to normal * 200 ' * AT#LDN = Set DTR to normal * 210 ' * AT#LX2 = Set for XON/XOFF flow control * 220 ' * ATS7=30 = Set wait for answer tone to 30 seconds * 230 ' * ATM0 = Turn speaker off * 240 ' * ATV1 = Issue long form of results codes * 250 ' * ATX2 = Full result messages * 260 ' * ATS57=1 = Hang up and reset automatically executed * 270 ' * ATE0 = Do not echo modem commands back to the PC * 280 ' * ATS10=10 = To cause to reset on loss of carrier faster * 290 ' * ATS58=3 = Force a 19200 Baud call to 9600 Baud locally* 300 ' * ATS22=46 = Suggested by the vendor * 310 ' * ATS0=0 = Don't answer until told to. * 320 ' * AT#W = Write settings to non volatile memory * 330 ' * * 340 ' ******************************************************************** 350 ' 360 OPEN COM.PORT$ + ":2400,N,8,1,RS,CD,DS" AS #3 370 PRINT #3,"AAAAAAAT" 380 PRINT #3,"AT#F" 390 PRINT #3,"AT#LCN" 400 PRINT #3,"AT#LDN" 410 PRINT #3,"AT#LX2" 420 PRINT #3,"ATS7=30" 430 PRINT #3,"ATM0" 440 PRINT #3,"ATV1" 450 PRINT #3,"ATX2" 460 PRINT #3,"ATS57=1" 470 PRINT #3,"ATE0" 480 PRINT #3,"ATS10=10" 490 PRINT #3,"ATS58=3" 500 PRINT #3,"ATS22=46" 510 PRINT #3,"ATS0=0" 520 PRINT #3,"AT#W" 530 SYSTEM RBBS-PC CPC17-2A Page 268 APPENDIX R -- RBBS-PC and the ZOOM Modem HC2400 ----------------------------------------------- In order to use the "ZOOM HC2400" modem with RBBS-PC parameter 225 should be changed as shown below. Only #2 and #5 need to be changed. Changes in #2. Add '&D2' just after 'AT'. Change 'S2=255' to 'S2=43'. Change in #5. Add "&D2' just after 'AT'. 1. Reset the modem : ATZ 2. Initialize the modem : AT&D2M0Q1S2=43S10=30E0Q0X1S0=0 Note: End item 2 with: S0=1Q0X1 if answer on 0 rings S0=254 if answer on >0 rings (no ring-back) S0=255 if answer on >0 rings (with ring-back) 3. Count the number of rings : ATS1? 4. Answer the phone : ATQ0X1V1A 5. Take the phone off the hook : AT&D2Q1E1H1M0 6. Clear the modem's firmware : AT&F 7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5 Note: End item 7 with: Q1 if item 2 ends with S0=255 8. Write to modem's firmware : &W For further information contact: Jeff L. Watts STATESVILLERBBS-PC Data # (704) 873-8482 RBBS-PC CPC17-2A Page 269 APPENDIX S -- RBBS-PC And The AT's RS-232 Cable ----------------------------------------------- The RS-232 serial connector is different for the AT than the PC or XT. The AT uses a connector called a DB-9, which is a 9 pin connector. An alternative to buying the AT serial cable from IBM, ($65-$80), is to make your own. A ten-wire cable can be purchased from any local computer store for about $.80 per foot, and the DB-9 and RS-232 connectors with hoods can be purchased from Radio Shack. The total cost should be about $12.00. A modem hooked up to the AT will work fine with the 9 pins connected in all terminal functions, except for auto-answer applications such as RBBS-PC. RBBS-PC requires pin 1 from the modem to be hooked up to the chassis ground on the AT or it can't answer the phone. There are two ways to hook up the ground wire on the computer end. The first way is to use a metal hood to cover the DB-9 connector. Wrap a bare wire that is attached to pin 1 of the RS-232 connector around the cable on the DB-9 end. When the metal hood is screwed down over the cable a connection will be made. When using a plastic DB-9 hood simply solder a wire from pin 1 on the RS-232 end to the metal body of the DB-9 connector. Since documentation is scarce for the AT, following figure lists the necessary pin connections for those wanting to make their own AT RS-232 cable. DB-9 RS-230 (Computer (Modem Description End) End) ========= ======= ================== GROUND -------- 1 -------- Protective Ground 1 -------- 8 -------- Data Carrier Detect 2 -------- 3 -------- Receive Data 3 -------- 2 -------- Transmit Data 4 ------- 20 -------- Data Terminal Ready 5 -------- 7 -------- Signal Ground 6 -------- 6 -------- Data Set Ready 7 -------- 4 -------- Request to Send 8 -------- 5 -------- Clear to Send 9 ------- 22 -------- Ring Indicator RBBS-PC CPC17-2A Page 270 APPENDIX T -- RBBS-PC And BASIC Compiler Patches for "Doors" ------------------------------------------------------------ Both the IBM Version 2.0 BASIC compiler and Microsoft's QuickBASIC compiler offers a lot of needed features to compiled BASIC programs. Regrettably, they also included a few "problems." For those who use RBBS-PC to "exit" to DOS (either via a "door" or as a remote SYSOP), the code generated by the new BASIC compilers would "help" you by dropping carrier when you chose to return to RBBS-PC from DOS or a "door." Help like this RBBS-PC didn't need. Jeff Porter was the first to document a six step "patch" to the IBM BASIC Version 2.0 compiler and to BCOM10.LIB of the QuickBASIC Version 1.0 compiler that corrects this problem within the logic of the code generated by the QuickBASIC compiler. Subsequently, Rod Bowman of "The PC Spectrum", (714) 945-2612,, subsequently, provided similar patches to the BCOM20.LIB of the QuickBASIC Version 2.0 and 2.01 compiler. As I stated earlier: "RBBS-PC continues to grow and expand because hundreds (and quite possibly thousands) of SYSOP's spend the time and trouble not only to modify RBBS-PC to meet their needs, but also to share these modifications with others." Please note that nowhere in the following documentation does Jeff describe the hours and hours it must have taken him to find the fix to the problem. Nowhere does he ask anything for himself for his efforts. As I have said so often "I am very proud of the company that RBBS-PC keeps." 1. DTR Patches for the QuickBASIC Version 1.x through 3.0 Compilers -------------------------------------------------------------------- As anyone who has tried to write any programs that use COM1: or COM2: with MicroSoft QuickBasic knows, the DTR modem control line is dropped every time a communication file is opened or closed. The original patch for the BASIC compiler was developed by Jeff Porter. Subsequently Rod Bowman supplied patches for the QuickBASIC compilers that followed. The 10 step procedure (7 if you have QuickBASIC 2.0 or above) is as follows: 1. Copy BCOMxx.LIB to BCOMxxBK.LIB where: xx = 10 for QuickBASIC Version 1.0, 1.1, and 1.2 = 20 for QuickBASIC Version 2.0 and 2.01 = 30 for QuickBASIC Version 3.0 2. Run DEBUG and load BCOMxx.LIB with the command: DEBUG BCOMxx.LIB 3. Display the following section of data with the command -dZZZZ L 10 where ZZZZ = 0540 for QuickBASIC Version 1.0, 1.1, and 1.2 = D368 for QuickBASIC Version 2.0 = D858 for QuickBASIC Version 2.01 = DC08 for QuickBASIC Version 3.0 4. Verify the data displayed contains the following sequence RBBS-PC CPC17-2A Page 271 nnnn:ZZZZ 83 C2 04 32 C0 EE EB If the data displayed contains the above sequence of numbers (they may be contained within the other numbers displayed), continue. Otherwise, go to section 2. 5. Assemble in the correct instructions for the patch as follows: Enter the command "-a QQQQ" where QQQQ = 054C for QuickBASIC Version 1.0, 1.1, and 1.2 = D36B for QuickBASIC Version 2.0 = D85B for QuickBASIC Version 2.01 = DC0B for QuickBASIC Version 3.0 The system will respond with the prompt "nnnn:QQQQ" where "nnnn" is what was shown in step 5 and QQQQ is what was entered in step 5. After this prompt enter a space and the instructions "mov al, 1". Press enter and at the next prompt hit enter without entering anything. This second enter informs DEBUG that you are finished assembling. 6. If you are not patching QuickBASIC Version 1.x, continue to step 9. For QuickBASIC Version 1.x, there is a second place that needs to be corrected. Display the following section of data with the command -d830 L 10 7. Verify the data displayed contains the following sequence rrrr:0830 83 C2 04 32 C0 EE EB If it doesn't, then go to section 2. It does continue on 8. Assemble in the correct instructions for the patch as follows: Enter the command "-a 0839". The system will respond with the prompt "rrrr:0839" where "nnnn" is what was shown in step 6. After this prompt enter a space and the instructions "mov al, 1". Press enter and at the next prompt hit enter without entering anything. This second enter informs DEBUG that you are finished assembling. 9. Now write the modified BASCOMxx.LIB out by issuing the command "w" at the prompt (i.e. "-w"). 10. Finally, quite the DEBUG session by issuing the command "q" at the prompt (i.e. "-q"). 2. Jeff Porter's DTR Patches for the IBM BASIC Version 2.0 Compiler -------------------------------------------------------------------- If you do not have MicroSoft QuickBasic or if you have a different version than I, you can probably still perform this patch. You will have to find the correct locations to patch. The addresses 054C and 0839 were found with the following procedure: 1. Search for the byte sequence 83 C2 04 32 C0 in the library file. If you are lucky, debug will find it in exactly two places. (for example:) -s 100 fff0 83 C2 04 32 C0 RBBS-PC CPC17-2A Page 272 2. Unassemble the addresses you found. The first two instructions will be ADD DX, +04 XOR AL, AL Within the next few instructions should be OUT DX, AL 3. If everything has gone correctly so far, just change the XOR AL, AL to a MOV AL, 1 4. Perform this change in both places where the XOR AL, AL instruction was found. 5. Write the updated file. 3. DTR Patch for the QuickBASIC Version 4.0 Compiler ----------------------------------------------------- The following are the instructions for modifying the original QuickBASIC 4.0 to keep DTR from dropping when returning from DOS/DOORS while running RBBS- PC. 1. Make a backup copy of the BCOM40.LIB file, just in case. 2. Run debug and load BCOM40.LIB A>debug bcom40.lib 3. Display the following sections of data and see that they match. This is to insure that you are patching the correct version of the library. -d 100 L 5 xxxx:0100 F0 OD 00 00 CA 4. xxxx may be different for each computer. Add 850 (hex) to xxxx in order to calculate yyyy. Remember these are hexadecimal numbers and this is hexadecimal addition. 5. Search for two occurrences of the offending code. -s yyyy:0 FFFF 83 C2 04 32 YYYY:A53F YYYY:A809 6. Unassemble the six bytes of code at the first location. -u YYYY:A53F L 6 YYYY:A53F 83C204 ADD DX,+04 YYYY:A542 32C0 XOR AL,AL YYYY:A544 EE OUT DX,AL If this is not what you find, do not proceed further. 7. Now unassemble the six bytes of code at the second location. -u YYYY:A809 L 6 YYYY:A809 83C204 ADD DX,+04 YYYY:A80C 32C0 XOR AL,AL YYYY:A80E EE OUT DX,AL If this is not what you find, do not proceed further. 8. Now change the code at the first location by assembling -a YYYY:A542 YYYY:A542 MOV AL,1 YYYY:A544 9. Now change the code at the second location by assembling -a YYYY:A80C YYYY:A80C MOV AL,1 YYYY:A80E 10. The patch is complete -- write the file back to disk and quit debug. -w Writing 331DD BYTES -q RBBS-PC CPC17-2A Page 273 This patch was developed by Rod Bowman of The PC-Spectrum RBBS-PC and documented by Jon Martin of the AIRCOMM RBBS-PC (415) 689-2090. The original QuickBASIC Version 4.0 has a know bug that precludes applications that SHELL to other applications when both the SHELLing application the application SHELLed to access the communication port. Therefore, RBBS-PC is distributed compiled under Version 3.0 of QuickBASIC. The practical effect of this QB4 bug is that the external file transfer programs can't be SHELLed to from RBBS-PC when RBBS-PC has been compiled with QB4. This DTR patch for QB4 does NOT fix the Microsoft SHELL problem in QB4! After QuickBASIC Version 4.0 was initially released, Microsoft started shipping a QuickBASIC Version 4.0B that does have the DTR patch incorporated in it and "may" fix the SHELLing problem. However, this has not yet been verified by RBBS-PC. 4. Patch for QuickBasic 4.5 ---------------------------- QuickBasic 4.5 is the first version QuickBasic not to drop DTR after terminating. Unfortunately, it does still drop DTR on some computers and some modems. The following patch was provided by Kenny Gardner, The Crow's Nest BBS, (714) 493-3819. Sound programming practices dictate that when you directly manipulate a hardware port, you restore that port to the exact same conditions it had prior to your touching it. In the case of DTR, this means that if DTR were ON when the QB program loaded, then DTR should remain ON when the QB program ends. If DTR was OFF when the program loaded, then fine, turn it OFF when the program ends. To the end that it is an ongoing struggle to get Microsoft to listen to the needs of the programmer, the following patches are provided to enable you to patch your copies of BRUN45.EXE and BCOM45.LIB. Before beginning, make sure you have backup copies of BRUN45.EXE and BCOM45.LIB. BCOM45.LIB DTR Patch -------------------- With Debug in a DOS path, type : debug bcom45.lib Type : s cs:0 ffff b0 00 e3 01 Debug should show : xxxx:1529 where xxxx can be any number depending upon where Debug loaded the program into memory. In any case, the number is not important. Type : RBBS-PC CPC17-2A Page 274 u 1529 Debug should show : MOV AL,00 JCXZ 152E INC AX ADD DX,+04 OUT DX,AL This is where QB graciously resets the comm port to parameters it thinks the comm port should have. To fix the problem, Type : a 1529 mov al,01 [Enter] a 152d nop [Enter] where [Enter] is the Enter key (do not type the characters)! To verify that you typed everything correctly, Type u 1529 Debug should show : MOV AL,01 JCXZ 152E NOP ADD DX,+04 OUT DX,AL To save the corrections Type : w Debug should show : Writing 35EF7 bytes Now type Q and you are finished patching BCOM45.LIB BRUN45.EXE DTR Patch -------------------- First, rename BRUN45.EXE to BRUN45.X RBBS-PC CPC17-2A Page 275 With Debug in a DOS path, type : debug BRUN45.X Type : s cs:0 ffff b0 00 e3 01 Debug should show : xxxx:9E78 where xxxx can be any number depending upon where Debug loaded the program into memory. In any case, the number is not important. Type : u 9e78 Debug should show : MOV AL,00 JCXZ 9E7D INC AX ADD DX,+04 OUT DX,AL This is where QB graciously resets the comm port to parameters it thinks the comm port should have. To fix the problem, Type : a 9e78 mov al,01 [Enter] a 9e7c nop [Enter] where [Enter] is the Enter key (do not type the characters)! To verify that you typed everything correctly, Type u 9e78 Debug should show : MOV AL,01 JCXZ 9E7D NOP ADD DX,+04 OUT DX,AL To save the corrections Type : w RBBS-PC CPC17-2A Page 276 Debug should show : Writing 12E80 bytes Now type Q and you are finished patching BRUN45.X Rename BRUN45.X back to BRUN45.EXE 5. DTR Patch for the BASIC Version 6.0 Compiler ----------------------------------------------------- This is a patch for BASCOM 6.0 that corrects the DTR/carrier drop problem. Bob Eyer developed it and Steve Kling verified that the patch work. There are two places in BASCOM's BCOM60ER.LIB that need patching. Each place requires a substitution for the following code: 83C204 ADD DX, +04 32C0 XOR AL, AL EE OUT DX,AL Just as in QB 1.x, the statement XOR AL, AL has to be changed to MOV AL, 1. First make a backup of BCOM60ER.LIB. Using Norton (or any good sector mod program), search for 83C20432C0EE. This string only occurs twice in BCOM60ER.LIB unlike QB, so any match needs patching. When found, change 32C0 to B001 and do it again. B001 is the opcode for MOV AL, 1 whereas from above you can see that 32C0 is XOR AL,AL. RBBS-PC CPC17-2A Page 277 APPENDIX U -- Using RBBS-PC to access ORACLE or dBASE Remotely -------------------------------------------------------------- 1. The Need for Data Base Services A feature that has been long missing from PC based host communication systems is the ability for SYSOPs to install customized data bases and let callers run true interactive data base queries against them. Because data base management is a major programming task, the most promising way to add data base services is to uses RBBS-PC's original and innovative "DOOR" mechanism to exit RBBS-PC and have the remote user enter an existing data base management program. "DOOR"ing to a data base management program, however, is not as easy as one might hope. The major problems stem from the fact that data base management programs are never designed to work in this environment. This is because: 1. Most programs write to the hardware for speed rather than use bios calls, causing the "screen" output to appear on the host terminal rather than on the caller's terminal. 2. Data base programs do not monitor for carrier. If carrier drops they simply sit forever waiting for input rather than terminating. 3. Most use "full screen" rather than "line at a time", which usually does not work properly on a remote terminal. 4. Security. Most data base programs have no way to limit what a user can do. For example, they do not have a read-only mode, or the ability to restrict a user to specific files or fields. Many let the user issue dos commands inside them, which gives to call too much power. 5. Difficulty in learning to use. A caller can hardly be expected to know how to use a data base. Hence it must be possible to simplify and control the user interface inside the data base package. Progress has been made with two of the most popular PC data bases -- ORACLE and dBASE! Using dBASE "DOORS" with RBBS-PC -------------------------------- db/LIB is a relatively new piece of software by AJS Publishing of North Hollywood, CA that makes remote dBASE access possible. db/LIB is a set of two assembled libraries which can be used to create/modify dBASE data structures, create/update dBASE indices, and naturally manipulate the dBASE records. These libraries also have many replacements for dBASE functions/commands not easily replicated (ie. IIF, RECNO(), DATE(), RTRIM(), DELETED(), etc.) outside of the dBASE environment. db/LIB is currently developing a multi-user version that should be released for testing by the end of January 1989. db/LIB was designed to work with Microsoft Quick BASIC 4.0 and BASIC Compiler 6.0 (there is a QB 2/3 version available directly from AJS Publishing after you purchase db/LIB). dBASE Remote Access Advantages/Disadvantages Combine db/LIB with any well written door skeleton (such as the very fine skeleton) and you can have a true shareable remote database system. The following section highlights some advantages and addresses the problems concerning remote dBASE database access. Advantages of using db/LIB and dBASE data bases: 1. Purchase of dBASE is not required. db/LIB can create modify and RBBS-PC CPC17-2A Page 278 maintain any dBASE structure. A program with db/LIB and downloaded by a third party can give these same freedoms to a third party. Sample programs with db/LIB demonstrate that most of dBASE's functions can be replicated or substituted using db/LIB. 2. If dBASE (or any good clone) is owned, then the two work very well in tandem. The programmers at Ashton-Tate didn't gain their reputation for writing junkware. By owning dBASE, the user can download any database structure and perform any data manipulation easily in a familiar environment. 3. Full screen (ANSI) writes, security, carrier monitoring, error trapping, are all handled by the door skeleton. Let database modules run the database, and let the door modules run the door. Disadvantages of using db/LIB and dBASE data bases: 1. Remote dBASE database access is not the same as accessing dBASE III remotely. Creation of these DOORS requires knowledge of Quick BASIC, some knowledge of data communications, and some knowledge of dBASE. All end user requirements have to be anticipated, all cases covered, and created in advance. Once the application is created, then user need no little or nothing about any of the above. 2. Not all users can use ANSI commands for full screen editing. This means that doors need to have a scrolling (terminal) type display capability as a substitute for the normal full screen writes. In some doors this will simply be impossible, preventing all users from database access. For those interested in dBASE-based on-line data base searches with RBBS-PC, you might try writing Steven Kling at 4009 Utah Ave., Brentwood, MD 20722. Steven is the author of BBS_BASE, USER_BASE and DoorBase. BBS_BASE is a non-ANSI dBASE III demonstration DOOR that maintains a database of Bulletin Board names, phone numbers, etc. This database can be queried, added to, edited, and up to the minute reports can be generated. The entire database with indices can be downloaded by the user for personal use. This database is indexed and therefore can be queried either by name or phone number. BBS_BASE was written only as a demonstration of using RBBS-PC to access a data base remotely. USERBASE is a dBASE registration door for RBBS 15.1C and above. It comes in both ANSI and non-ANSI versions and gives an automatic access upgrade capability to the SYSOP at his/her option. Steven Kling and Michael Kelly are collaborating on DoorBase, which has just been released, and this will give a SYSOP the capability to place any dBASE III database on-line, and will allow him/her to set up all the full screen display features to his/her own specification. DoorBase has multiple demonstration databases available including databases of Congressmen, dBASE vendor support companies, and a national BBS listing. Steven is also the SYSOP of Technopeasants' EAST RBBS at (301)-927-4258 Brentwood, MD (PC Pursuitable) 24 Hours/ 2400 baud. Michael is the SYSOP of Technopeasants' WEST RBBS at (503)-257-7070 Portland, OR (PC Pursuitable) 24 Hours/ 2400 Baud. Using ORACLE with RBBS-PC for On-line Data Base Access RBBS-PC CPC17-2A Page 279 ------------------------------------------------------ Another database package that is able to be used as a "door" is ORACLE from Oracle Corporation at One Oracle Parkway in Belmont, California 94002. Their number is (415) 598-8000. ORACLE is a very promising solution to providing remote data base services. Oracle addresses the problems mentioned earlier as follows. 1. Screen writes. ORACLE user bios calls. All output appears perfectly normal on remote terminals through the CTTY interface in RBBS-PC. 2. Monitor for carrier. Run WATCHDOG, which will reboot your system if carrier drops. 3. Full screen mode. ORACLE uses only ANSI commands to control the users screens. Callers whose remote communications package implements ANSI support therefore see full screen writes exactly the same as local users. FULL SCREEN WORKS! 4. Security. ORACLE has all the security you could ever want because it was designed for multi-user systems. 5. Usability. ORACLE implements SQL, which is increasingly becoming an industry standard that all major data base systems are supporting. Of course, there are some problems using ORACLE in a way in which it was never designed: 1. There is a problem getting the function keys to work properly remotely. 2. The ability for a caller to use DOS commands needs to be disabled within ORACLE. 3. Callers who do not know SQL need pre-structured queries and a menu interface to be designed for them. ORACLE supports a full screen interface but the user interface in ORACLE is not as programmable as one would like. For those interested in ORACLE-based on-line data base searches with RBBS-PC, you might try writing John Prior at P.O. Box 2168, Rockville, MD 20852-2168. Steve is the SYSOP of SQLBBS at (301)-881-6588 Rockville, MD (PC Pursuitable) 24 Hours/ 2400 baud. The SQLBBS is a specialized bulletin board system specializing in supporting relational data base managers and making the power of SQL available to callers. SQLBBS uses an RBBS-PC door to get into ORACLE. The SQLBBS has implemented ORACLE to help manage the data processing for the National Council for Children's Rights (NCCR), and have several major data bases on-line for general interest. People can contact John Prior, the SQLBBS SYSOP, on Compuserve or MCI, by mail, or call SQLBBS if they wish to see how ORACLE is implemented, get the latest progress report, or share experiences implementing data base services. Here are details on the SQLBBS system and how to reach both John and it: Modem: 2400 Baud Hayes BBS Number: 301/881-6588 Hours: 24 hrs/day RBBS-PC CPC17-2A Page 280 Address: Prior Computer Service Inc. POB 2168 Rockville MD 20852-2168 Compuserve ID: 76266,1072 MCI MAIL ID: JPRIOR SYSOPS: John F. Prior Steve J. Prior Tony Zelof SQL Tables Roster of the House of Representatives Available Roster of the Senate [both with addresses etc.] Now The States [2 char abbreviation and full name] Call SQLBBS as you would any other RBBS-PC system. Go through the Door. SQLBBS executes a "SELECT * FROM TAB;" for you which shows you the tables and views you can access. At the UFI> prompt execute any SELECT command you want against any table or view. "SELECT * FROM STATES;" returns all rows [records] of the STATES table. "SELECT * FROM STATES WHERE ST = 'MA';" returns all rows about the state whose two-character code is "MA". "SELECT COUNT(*) FROM STATES;" gives you a count of the rows in the STATES table. If you substitute another table or view instead of STATES such as SENATE, you can access other tables/views. "DESC HOUSE" would return the column names of the HOUSE table. "HELP" gets you help. "HELP SELECT" gets you help on the SELECT command. "HELP SET" gets you help on the SET command which can control many options for display "SHOW ALL" shows you everything you can SET. "EXIT" terminates UFI and returns you to RBBS-PC. RBBS-PC CPC17-2A Page 281 APPENDIX V -- Using RBBS-PC with SEAdog to Access FIDO-NET ---------------------------------------------------------- SEAdog is a full-featured electronic mail system based on the personal computer and using standard telephone lines. It is a sophisticated store- and-forward mail system which can be configured in a virtually unlimited number of network topologies (more on this later). Unlike some network systems, the end user need never concern himself with network routing -- it all happens automatically. The user just submits and retrieves messages, the system takes care of the details. The hardware needed to run RBBS-PC is sufficient to run SEADOG. SEAdog uses the FidoNet Electronic Mail Protocol, as defined in the document, A Basic FidoNet Technical Standard, published by the International FidoNet Association (IFNA). The FidoNet Protocol is a public domain electronic mail standard originally developed by Tom Jennings for the Fido bulletin board system. For more information about the FidoNet Protocol, please write to: The International FidoNet Association P.O. Box 41143 St. Louis, Missouri 63141 United States of America There are several advantages to using the FidoNet Protocol, not the least of which is that a great many utilities and programs are available from many different vendors for doing various things with electronic mail. Please contact IFNA at the above address for more information. The heart of SEAdog is the network mail server, MAILER.EXE. This is the program that places and receives phone calls, handles message routing, and so forth. It is left running when you would normally turn your machine off. You can set RBBS-PC to drop to DOS at a time when telephone costs are cheapest (normally 4AM Eastern Standard time and 1AM Pacific time) and invoke the mailer so that it begins placing phone calls to other SEAdog systems to pass them your outgoing mail and receive your incoming mail. SEAdog costs $100.00 and can be ordered from the address or phone number below. Thom Henderson SYSTEM ENCHANCEMENT ASSOCIATES 21 Wayne Street Wayne, New Jersey 07470 V:201-473-5153 This doc file is not intended to replace the SEAdog manual, but rather provide information that an RBBS-PC SYSOPsysop would find useful when configuring RBBS-PC to run with SEAdog. The current status of the RBBS-PC - SEAdog project is at the level in which RBBS-PC has the ability to be front-ended by SEAdog in where SEAdog will turn over to it a live, active modem with a caller waiting. RBBS-PC has been modified to accept two additional command line parameters which can alter the defaults in RBBS-PC.DEF. Currently, that is the extent to which RBBS-PC and SEAdog can be used together. The Fido message base format is not yet compatible with RBBS-PC. It is assumed that you are reading this because you are familiar with the RBBS-PC and have at least a minimum knowledge of FidoNet and FidoMail. RBBS-PC CPC17-2A Page 282 Another assumption is that you have RBBS-PC up and running on your computer. The easiest way to get all two programs working together is to have each running from it's own subdirectory on your hard disk. That'll make maintenance of RBBS-PC and SEAdog specific files much easier. Follow the instructions in the SEAdog manual to install it, if that hasn't been done yet. Once installed all SEAdog files will be in a subdirectory called \MAIL. Make any required modifications to your CONFIG.SYS as suggested in the SEAdog manual. If your using DOS 3.xx, and don't use the DOS SUBST command, you should consider doing so. SUBST is a DOS external command that allows you to SUBSTitute a drive letter for a complete subdirectory name. Using this command will make reprogramming RBBS-PC's configuration file easier. This appendix assumes that all the SEAdog Files are in a subdirectory called C:\MAIL and those for RBBS-PC are in a directory called C:\RBBS. A further assumption that is made is that a new drive "H:" will be SUBSTitued for the C:\RBBS subdirectory. Since SEAdog will be in controls most of the time, the entire operation should use SEAdog's C:\MAIL directory as the default. Now load and run CONFIG.EXE and reprogram it's configuration to reflect that all RBBS's help, menu and system files are located on the "H:" drive. Remember the SUBSTitute command? You can use it to replace those long subdirectory names for download and upload files. SPECIAL ATTENTION must be paid to CONFIG.EXE's parameter 163. This parameter MUST be set to SYSTEM recycle. Not doing so will cause RBBS-PC to reload itself after a caller has hung up or dropped carrier and not pass control back to SEAdog. The SEAdog manual explains various commands that must be placed in it's configuration file called CONFIG.DOG. Among those that are considered a minimum, you should include at least the following.... banner Please stby, 15 secs to load RBBS-PC bbs H:RBBS *T *B event B all 4:30 5:00 ;Local collections event A all 5:00 6:00 ;National FidoMail Window event C all 6:00 7:00 ;Local distributions event S all 7:00 4:00 Crash Dynamic BBS ;CRASH mail if not in RBBS event X10 all 7:00 7:05 ;Reboot Computer The banner statement should be used so that human callers know why there is a delay from the time they connect until the time they see RBBS-PC display it's welcome message. The bbs command tells SEAdog what batch file to run when passing control to RBBS. *T and *B must be in the order presented above in for RBBS-PC to pickup and use them correctly. They pass the time remaining to the next scheduled SEAdog event and the baud rate the caller came on with. Event statements tell SEAdog how to schedule it's time during the day. The above example conforms to the FidoNet national mails hours as of 26 July 1987 and allows crash mail and bbs operation at all others. Since the SEAdog *P parameter in the bbs command isn't used, you must insure that the comm ports used for RBBS-PC and SEAdog are the same. One of the more confusing decisions will be how to setup the modem switches. Without going into it too deeply, keep in mind that SEAdog will be controlling the modem and passing an active modem on to RBBS-PC. RBBS-PC CPC17-2A Page 283 Additionally, you could have your SEAdog upload and download areas overlap those of RBBS-PC. When SEAdog determines that a non SEAdog or Fido system has called, it runs a second copy of DOS, then optionally loads and runs RBBS-PC via direct command or from a batch file, passing the speed that the comm port was opened at, and the time remaining to the next scheduled SEAdog mailer event as in the following example: SEAdog calls RBBS-PC via a batch file called RBBS.BAT C>RBBS-PC 1 H:RBBS-PC.DEF /%1 /%2 | | | | |> Baud Rate | | | | | | | | | | | |> Limits the amount of time the user has | | | this session if and only if the time is | | |less then the time per session specified |||in CONFIG.EXE. | | |> RBBS-PC default file filespec (Optional) | |> Node number that the specified .DEF file applies to. |(Optional) |> The name of the RBBS-PC program. With a properly configured RBBS.BAT batch file, you can retain all the functions of RBBS to include DOORS and dropping to DOS via SysOp function #7. See the sample batch files at the end of this file. Experience has shown that the best way to run RBBS-PC and SEAdog is with a batch file, where SEAdog having determined that a non mailer system is waiting to use the bbs will load and run a batch file that controls RBBS- PC's operation as opposed to SEAdog calling RBBS-PC directly. Two batch files are used, one to control SEAdog and one to control RBBS. A minimum batch file is suggested in the SEAdog manual. In addition to what ever you place in it, add the following statements to it. If Exist H:RCTTY.BAT Del H:RCTTY.BAT This line should be the first. This statement simply helps ensure proper operation of RBBS-PC if you use SYSOP function #7 or DOORS. If Errorlevel 10 Goto REBOOT: This line goes after the line that contains the call to the MAILER program. REBOOT: IPL This line reboots the computer every morning according to event listed above. Due do unexplained loss of memory when running SEAdog and RBBS-PC, is safe to program in a scheduled rebooting of the computer to regain any loss of memory. This line should be near the last and programmed around for normal operations ** Ex RBBS batch file ** Echo Off :LOOP C: RBBS-PC CPC17-2A Page 284 Cd \MAIL If Not Exist H:RCTTY.BAT Goto LOCAL H:WATCHDG1 OFF Del H:RCTTY.BAT H:TESTRBBS 1 H:RBBS-PC.DEF Goto REMOTE :LOCAL H:TESTRBBS 1 H:RBBS-PC.DEF /%1 /%2 :REMOTE If Not Exist H:RCTTY.BAT GOTO EXIT H:WATCHDG1 ON H:RCTTY.BAT :EXIT As mentioned above, this doc file isn't intended to make you completely knowledgeable on how to interface RBBS-PC and SEAdog, only get you started. How you set up your RBBS-PC and SEAdog batch files is limited only by your ability and imagination. After gaining more experience, you'll find that you can automate a lot of the RBBS-PC and SEAdog maintenance. The above reflects the creative things that Kim Wells, Fido Address 109/652, has done with interfacing RBBS-PC with the Fido net-mail system. If you need further help, contact Kim Wells's RBBS-PC via his data line at (301) 350-1299. RBBS-PC CPC17-2A Page 285 APPENDIX W -- DOS Limitation on Running Programs Remotely --------------------------------------------------------- When accessing your PC via a communications port, the carrier detect signal tells the PC that you are on-line. DOS's major limitation is that there is no way to tell DOS to monitor carrier detect automatically when the standard input and output is transferred to a communication port (i.e. via the CTTY command). RBBS-PC makes sure that the carrier is not dropped when a user exits to DOS either via the "DOORS" option or using the remote SYSOP function 7. However, it is the SYSOP's responsibility to insure that whatever programs are invoked after leaving RBBS-PC perform all the necessary functions to maintain the communications session and, when exiting to return to RBBS-PC, that the carrier is "NOT" dropped. Most application programs (i.e. databases, etc.) are not designed to be controlled by users accessing them from a communications port. This problem is solved when a function is invoked that: 1. Checks to see if the standard input and output console have been assigned to an auxiliary console such as a communication port. 2. If condition 1 is true, checks to see if the carrier detect signal is lost by intercepting each interrupt from the communication port the auxiliary console has been assigned to. 3. If BOTH conditions 1 and 2 are true, this function would cause DOS to return to the standard screen and keyboard for its operations AND continue processing whatever batch file that had been executing. Such a function (or device driver) would provide a "fail safe" feature that would allow users to exit RBBS-PC to use whatever other software the SYSOP chose to make available (i.e. relational databases for complex inquiries -- bibliographic, sports, games, etc.). For those anticipating using RBBS-PC's "doors" or exiting to DOS when you are a remote SYSOP, you are strongly encouraged to consider using the "watchdog" utility program available on many bulletin board systems under such file names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that monitors the communication port for you and reboots your system if carrier drops. If you don't use a program like WATCHDOG and accidentally hang up while in a "door" or in DOS, you system will remain "hung" until you can manually reboot it. Programs that utilize the PC's built in video memory (such as the IBM BASIC interpreter or WordStar when it writes to the 25th line) need to have such I/O redirected in a special way to a remote users terminal. Additionally, if the I/O is redirected to the communications port, the terminal on the other end must have a "cursor" that can be sent the appropriate command sequence to move it around on the remote users terminal as necessary. Without this capability, programs made available through "doors" must be line-at-a-time programs. This of course excludes programs such as WordStar, Lotus/123 etc. If you aren't technically inclined and want to use RBBS-PC "doors", I suggest you consider only using programs that have been explicitly written to overcome the above two DOS limitations. Applications that don't write directly to the video memory of the PC can be used safely as a "door" as long as a "watchdog" type program is also used. RBBS-PC CPC17-2A Page 286 APPENDIX X -- Using RBBS-PC with DoubleDOS ------------------------------------------ Two nodes of RBBS-PC can be operated on one 640K PC/XT/AT under DoubleDOS. First, make sure DoubleDOS and RBBS-PC, individually, operate correctly on your computer. Then, the DDCONFIG.SYS file can be changed to facilitate operation of RBBS. SoftLogic Solutions, the DoubleDOS supplier, operates a customer service BBS at 603-644-5556 and can often help with special problems. (An example: DoubleDos version 4.0 must be modified with their special patch in order to operate on machines using EEMS memory controlled by AST's REMM.SYS driver.) DoubleDOS even has a special interrupt that RBBS-PC calls to "give back" unused time to the foreground job when it really doesn't need the time, so that during periods of low communications activity, the foreground job runs at essentially 100% of the machine's speed. GIVEBACK is incorporated into releases CPC16-1A (and greater) of RBBS-PC. The DOS (3.1 or greater) utility SHARE should be run before starting DoubleDOS to provide for file locking. RBBS-PC, due to the code generated by the BASIC compiler, requires a considerable amount of memory. If insufficient memory is available, RBBS- PC may fail to load, may report a string corrupt error, may hang, or, worst of all, may appear to start and operate normally only to fail later. A (partial) test of whether enough memory is available is to note the DS free space in the SYSOP initial menu when operating under DoubleDOS compared to naked DOS; any reduction in this reported free space may indicate memory shortage. The best approach, unfortunately, is to start with more memory than necessary, get your system going reliably, and then do a crude cut- and-try process of reducing memory until problems first appear; then back off up to an again-reliable memory setting. Terminate-and-stay-resident programs (e.g. ramdisks, print spoolers, Side Kick) will reduce the memory available to RBBS-PC. Buffers specified in the CONFIG.SYS file also reduce available memory. Some versions of DOS are smaller than others; every little bit of memory helps. Large programs may not run in the second DoubleDos memory section after starting RBBS-PC in the first. Because of these memory considerations, SHELLing to DOORS and external file transfer protocols will not be possible. If these features of RBBS-PC are used, they will need to be invoked by EXITing to them. The BASIC compiler version used determines the amount of memory required. Two nodes of RBBS(version 16.1A), have been demonstrated to operate successfully under DoubleDOS when compiled with Quick Basic 1.02 and RBBS- PC's memory requirements reduced (see Appendix Y). When compiled with Quick Basic 2.x, 3.x or 4.x, two nodes will not fit under DoubleDOS. To save memory, expert SYSOPS who are adept at compiling/linking their own custom versions of RBBS-PC, can selectively (and at their own risk) delete from the source code sections that they do not require. Such personal versions should not be circulated to others. If this is done, the more recent compilers may produce code compact enough for 2 nodes. DoubleDOS has several parameters that can improve RBBS-PC operation. Sample: menu = short ;the long menu requires more memory display = text ;to not reserve graphics buffer print driver = direct ;use direct drive, no buffer reserved RBBS-PC CPC17-2A Page 287 bottom size = half ;split memory for two RBBS nodes priority = equal ;both nodes run at same speed The next items may be desirable to provide protection, in case any program in the other memory section should try to use a COM port assigned to RBBS- PC. com1 = top ;obviously these two port assignments com2 = bottom ;could be reversed Possible circumstances that might warrant this protection: 1.SYSOP makes a COM port assignment error in the .DEF file for the other node. 2.one node is temporarily shut down by the SYSOP to run another program. Some programs (e.g. some versions of BASIC) initialize both COM ports (clobbering RBBS-PC) when started. Warning: this protection is known to be unusable on some machines (e.g., works fine on IBM-PC 8088, does not work on AST Premium 286 or TATUNG 4000 AT). It is convenient (and safer, to prevent keystroke errors) to automate your startup. In your AUTOEXEC.BAT file you should initiate DOUBLEDOS as the last item. It will then start, using the DDCONFIG.SYS file for detailed RBBS-PC instructions. Sample DDCONFIG.SYS contents (this will vary according to your exact setup): top program = prompt TOP $p$g top program = go bottom program = prompt BOT $p$g bottom program = go Note that the change in prompt allows a single batch file, GO.BAT, which has the single statement of GO%PROMPT%, to execute the correct node of RBBS-PC in either node. Nothing is more embarrassing than to start a node that is already operating. All that need be typed is GO<RETURN> and either GOTOP or GOBOT will be executed. (Actually the GO batch file execution looks like "TOP C:\DDOS>GOTOP $p$g". The $p$g is ignored.) GOTOP.BAT might then look like this: C: CD\RBBS RBBS1 RBBS1.BAT would then be the first node RBBS.BAT as discussed in this document. Similarly, GOBOT would start RBBS2.BAT for the second node. Stan Staten, RBBS-PC number (301) 670-9621 Kurt Riegel, RBBS-PC number (202) 524-1837) RBBS-PC CPC17-2A Page 288 APPENDIX Y -- Recompiling RBBS-PC to Reduce Memory Required ----------------------------------------------------------- RBBS-PC has always sought to live up to CPCUG's Bill of Rights for Software Users which maintains, among other things, that each software user has a right to "integrate software products into his or her system environment without undue constraints." For this reason, RBBS-PC has chosen to be as configurable as possible through the program CONFIG with over 200 different parameters. Additionally, RBBS-PC has always been distributed with the complete BASIC source code with each new release. It is this kind of leadership (by example) and recognition of software users rights that makes RBBS-PC unique in the personal computer industry. RBBS-PC is continually being enhanced with new features. As new functions and capabilities are added, RBBS-PC's memory requirements grow correspondingly. In order to continue RBBS-PC's growth and still meet the memory constraints imposed on SYSOPs with only 640K of memory who wish to run two copies of RBBS-PC, RBBS-PC source code can be "mite-sized" and recompiled to fit within whatever memory constraints a SYSOP must deal with. SYSOPs can apply .MRG files against the unmodified RBBS-PC source code and elect to eliminate RBBS-PC features not being used and eliminate redundant code (typically the BASIC source code that replicates assembly language routines). RBBS-PC Version CPC17-2A has a companion "mite-size" set of files contained in the file LIT-172A.ARC dated 04/30/89. In order to recompile and "mite-size" RBBS-PC, within the same environment in which the SYSOP has successfully recompiled the current release of RBBS- PC Version CPC17-2A the SYSOP must also have the following files: BLED.EXE --The Batch Line EDitor by Ken Goosens (version 2.2 or greater). MAKELIT.BAT --The BATch file that invokes BLED.EXE and applies the necessary files to the unmodified source code. This file should be modified by putting in the drive/path for the original code (the first parm to BLED). The lines to be modified all begin with "*$", which is the default for a BLED metacommand. The lines beginning with "* " are BLED comments, which are ignored in a merge. SETLIT.INC --The file through which the SYSOP selects the RBBS-PC features that are not needed. The directions for doing this are contained within this file. A feature is typically removed by setting a BLED metacommand variable to "OFF", e.g. BAUD450 to "OFF" to save code by excluding the RBBS-PC feature that allows 300 baud uses to increase their baud rate to 450 while on-line. To exclude RBBS-PC LIBRARY subsystem set LIBRARY to "OFF". RBBSLIT.MRG -- The fundamental BLED merge for CPC17-2A's RBBS-PC.BAS SUBxLIT.MRG -- The fundamental BLED merge for CPC17-2A's various RBBSSUB's. Each reads in (includes) the file SETLIT.INC to set the metavariables used by BLED. BLED then uses the values to determines what merges to process. *.LIT -- .MRG files that eliminate RBBS-PC features. The procedure for "mite-size"ing RBBS-PC Version CPC17-2A is as follows: 1. Select the RBBS-PC features not required for your needs and modify the file SETLIT.INC. 2. Change MAKELIT.BAT to reflect your PC's subdirectories. RBBS-PC CPC17-2A Page 289 3. Make sure RBBSSUB1.BAS is in the subdirectory you will run in. 4. Execute the MAKELIT.BAT file. Do not continue if errors are found. 5. Recompile the "mite-siz"ed RBBS-PC source code. Remember, this "mite- sized" source code and the RBBS-PC.EXE file created from it my only be used by you and not distributed to others. Some comments on the various Microsoft QuickBASIC compilers: QuickBASIC Version 1.02 produces the smallest code. QuickBASIC Version 2.01 produces the next smallest code. QuickBASIC Version 3.00 produces the largest code. QuickBASIC Version 4.5 produces code smaller than 3.00) but is not as reliable Never LINK with the /E option. 6. Re-run CONFIG and disable the RBBS-PC features that were deleted in the "mite-sized" version that was created in steps 1 through 5 (i.e. take out the "A" command if questionnaires were disabled). Please realize that there is no way that the "mite-sized" variations of RBBS-PC can be supported. The many different PC configurations plus the multitude of combinations of RBBS-PC features are what make this impossible. However, we will do our best. Please report any problems with BLED or the *.LIT merges to Ken Goosens via his RBBS-PC data number -- (703) 978-6360. RBBS-PC CPC17-2A Page 290 APPENDIX Z -- The MICROCOM AX\9624c RBBS-PC Switch Settings ----------------------------------------------------------- First set the Microcom AX\9624c switch settings as follows: CONFIGURATION SWITCH SETTINGS FOR THE MICROCOM AX\9624c MODEM ============================================================= 1 2 3 4 5 6 7 8 9 10 -------------------------------------- Front Switch - U D D D D U U D U U Rear Switch - U U D U D D D D - - Change CONFIG parameter 228 to open the modem initially for 9600 baud. Then go to CONFIG parameter 225 and change some of the default Hayes commands. Within parameter 225, you will want to change the second command, "Initialize the modem." If you want RBBS-PC to answer on one ring set it to: ATM0Q1S2=255S10=45E0S0=254&D2 To answer on zero rings, set it to: ATM0Q1S2=255S10=15E0S0=0Q0X1&D3 Please note that these change the default Hayes commands supplied with RBBS-PC for S10. Also note that an &D command was added to the end. If you are set up to answer on ring zero and your modem sometimes stops answering for no reason that you can isolate, alter the S10 value to "45" and &D2. You may also want to activate CONFIG parameter 236 to "wake up" the modem. These configurations will allow RBBS to establish a MNP reliable or non- reliable connection from 300 to 9600 BAUD using the AX\9624c's MNP class 6 Universal Link Negotiation capability. RBBS-PC CPC17-2A Page 291 APPENDIX AA -- The Leading Edge Series L 2400B Modem ---------------------------------------------------- Gregg Snyder, SYSOP of "The Elusive Diamond" - DGS (Alpha) System, and Jim Thompson of "The Break" -DGS (Delta) System (Data: 703-680-9269) are to be created with documenting how to get the Leading Edge Series L 2400B modem to run with RBBS-PC ("all modems are Hayes-compatable, but some are less Hayes-compatable than others"). First you must set CONFIG parameter 228 to open the modem at 1200 baud. Next go to CONFIG parameter 225 and set the modem commands as follows: 1. Reset the modem : ATB1H0L1M0C1 2. Initialize the modem : ATH0B1L1M0Q1E0S0=254 Note: End item 2 with: S0=1Q0X1 if answer on 0 rings S0=254 if answer on >0 rings (no ring-back) S0=255 if answer on >0 rings (with ring-back) 3. Count the number of rings : ATS1? 4. Answer the phone : ATQ0X1V1A 5. Take the phone off the hook : ATH1L1M0 6. Clear the modem's firmware : AT&F 7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5 Note: End item 7 with: Q1 if item 2 ends with S0=255 8. Write to modem's firmware : &W These settings have been tested for more than a year by Jim Thompson beginning with RBBS-PC CPC15-1C. ================= END OF RBBS-PC CPC17-2A DOCUMENTATION ==================